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PREFACE 


As  part  of  Its  efforts  In  support  of  the  Aoa1  programming  language,  the  Ada 
Joint  Program  Office  (AJPO)  Is  deeply  involved  with  the  production  of  tools  that 
will  support  Ada  programmers.  An  ADA  Programming  Support  Environment 
(APSE)  Is  Intended  to  Include  a  rich  collection  of  tools  such  as  compilers, 
editors,  pretty-printers,  cross-reference  generators,  verifiers,  and  so  on.  to 
assist  the  programmer  using  the  APSE  and  to  ease  the  difficult  task  of  creating 
the  complex  software  required  for  DoO  applications. 

Early  In  the  design  of  Ada  compilers,  the  contractors  Involved  chose  Diana  as 
the  notation  to  be  used  for  communication  between  the  components  of  the 
compilers  they  were  building.  Diana  Is  an  abstract  data  type,  designed  with  the 
Intention  that  any  object  of  the  type  represents  all  the  information  in  an  Ada 
source  program,  along  with  the  results  of  lexical  analysis,  syntax  analysis,  and 
static  semantic  analysis.  Further.  AJPO  has  long  realized  that  Ada  is  not  the 
proper  lingua  franca  to  be  used  as  a  means  of  communication  between  the  tools 
In  an  APSE  and  that  Oiana  Is  In  fact  an  excellent  notation  for  the  purpose. 

Diana,  like  Ada.  did  not  spring  forth  perfect  from  the  pens  of  Its  creators. 
Ada  has  had  the  benefit  of  a  long  process  of  Informed  feedback  from  Interested 
computer  specialists  to  bring  to  Its  present  state  of  excellence;  Diana  requires 
similar  nurturing  and  care  for  It  to  grow  Into  a  mature  tool  that  properly  meets 
the  widely  varying  needs  of  Its  user  community.  AJPO  has  therefore  contracted 
with  Tartan  Laboratories  to  maintain  Diana  and  to  Improve  it. 

One  Issue  which  we  at  Tartan  have  addressed  In  this  effort  has  been  to 
determine  Diana's  suitability  for  an  application  other  than  a  compiler.  Although 
Diana's  original  design  contemplated  such  non-compiler  applications,  essentially 
all  of  the  existing  experience  has  been  with  compilers,  so  only  compiler  applica¬ 
tions  have  had  the  opportunity  to  Influence  Diana's  continual  development.  Thus 
we  have  designed  a  program  named  PrettyPrint  which  is  a  pretty-printer  for  Ada 
that  uses  as  Input  a  Duma  representation  of  an  Aoa  program.  It  Is  the  design  of 
PrettyPrint  that  Is  described  In  this  document. 


1Ada  it  •  registered  Trademark  of  tho  Ada  Joint  Program  Office,  Department  of  Defen  to,  United 
Statee  Government. 
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A  pretty-printer,  a  tool  that  belongs  In  the  tool  chest  of  any  group  writing 

large  amounts  of  code,  enforces  standards  of  layout  on  the  page  of  programs 
written  In  the  ianguage.  In  the  usual  case,  the  pretty-printer  reads  one  version 
of  the  program  to  be  formatted  and  writes  a  new  version,  properly  formatted. 
However.  In  an  environment  such  as  an  APSE*  ft  Is  more  appropriate  for  the 
pretty-printer  to  take  as  its  Input  a  Diana  representation  of  an  ADA  program, 
rather  than  textual  Ada. 

It  is  Important  for  the  reader  to  keep  In  mind  that  the  purpose  of  the  design 
has  been  to  exercise  various  aspects  of  Diana,  and  not  to  build  a  better 
pretty-printer.  This  point  Is  addressed  more  fully  In  Section  1.1  of  this  docu¬ 
ment. 

This  document  assumes  that  the  reader  Is  familiar  with  the  programming 
language  Ada.  as  it  Is  defined  In  Draft  Revised  MIL-STD  1815.  the  Ada  Language 
Reference  Manual  dated  July  1982  [2].  It  also  assumes  knowledge  of  Diana  as 
defined  In  the  Diana  Reference  Manual  (hereafter  referred  to  as  the  DRM)  dated 
February.  1983  [1]. 

The  work  reported  herein  has  been  supported  by  the  Ada  Joint  Program  Office 
under  contract  MOA903-82-C-0T48.  We  thank  AJPO  for  supporting  the  Diana 
revision  effort  of  which  the  the  design  of  PretiyPrint  Is  a  part.  We  thank  In 
particular  Lt.  Colonel  Larry  Druffel.  the  director  of  AJPO.  Valuable  assistance  as 
Contracting  Officer's  Technical  Representative  was  provided  first  by 
Lt.  Commander  Jack  Kramer  and  later  by  Lt.  Commander  8rian  Schaar;  we  are 
pleased  to  acknowledge  them. 
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CHAPTER  1 
INTRODUCTION 


This  report  presents  the  design  of  PrettyPrint.  a  program  designed  to  accept 
as  Input  a  Diana  representation  of  an  Aoa  program  and  to  produce  as  output  a 
properly  formatted  textual  version  of  the  same  Ada  program. 

This  introductory  chapter  contains  In  succeeding  sections  the  goals  of  the 
PrettyPrint  design  project,  an  overview  of  the  design,  some  comments  about 
Diana,  some  comments  about  the  design  of  PrettyPrint.  and  an  overview  of  the 
rest  of  the  document. 

1. 1.  Goals  of  the  Design  of  PREmPnerr 

As  stated  In  the  Preface,  the  purpose  of  this  design  exercise  has  not  been  to 

investigate  pretty-printers  as  such  but  rather  to  test  and  stress  various  aspects  of 

the  design  of  Diana.  Thus  the  design  has  been  strongly  Influenced  by  the  two 
goals  of  Investigating  Diana's  suitability  for  a  non-compller  application  and  of 
stressing  the  design  of  the  Diana  interface  package.  We  have  regarded  these 
goals  as  being  so  important  that  we  have  sacrificed  considerations  of  elegance  of 
design  and  of  efficiency  and  compactness  in  order  to  achieve  them.  They  are 
considered  in  detail  in  the  next  two  subsections. 

1.1.1.  Non-Compller  Application 

The  primary  purpose  for  this  design  has  been  to  exercise  Diana  In  an 
application  domain  other  than  a  compiler.  Most  current  users  of  Diana  employ  It 
in  compiler  writing.  However,  inasmuch  as  Diana  was  Intended  also  to  be  a 
useful  Intermediate  form  for  many  of  the  tools  to  be  found  in  an  APSE,  it  is 

imperative  that  its  design  be  stressed  by  using  It  in  such  an  application. 

PrettyPrint  is  clearly  one  non-compller  tool  that  uses  Diana. 

Crucial  to  the  use  of  Diana  for  driving  any  tool  such  as  PrettyPrint  is  the 
Diana  design  principle  (presented  in  Section  1.1.1  of  the  DRM1)  that  Diana  must 
proserve  the  structure  of  the  original  source  program.  Our  success  in  designing 


1Aa  Mated  In  the  Prefeoe,  we  uae  DRM  to  refer  to  the  Diene  Reference  Menuel. 
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PncmPfttNr  has  made  it  adequately  clear  that  the  source  structure  Is  preserved. 


1.1.2.  Exercise  the  Diana  Package 

PrettyPrint  should  exercise  the  Diana  package.  Since  Diana  Is  an  abstract 
data  type,  for  which  many  possible  concrete  representations  can  be  d*<n.ed  in 
any  reasonable  programming  language,  defining  a  specific  concrete  represen¬ 
tation  in  Ada  Is  a  practical  Idea.  In  Aoa  such  a  definition  would  consist  of  a 
package  whose  specification  contains 

•  the  relevant  type  definitions  (some  private),  and 

•  specifications  of  subprograms  to  access  ob)ects  of  the  type. 

The  body  of  the  package  would  contain  the  bodies  of  those  subprograms  and. 
likely,  other  types  and  subprograms. 

Chapter  4  of  the  DRM  contains  the  public  part  of  a  specification  for  such  a 
package,  named  Diana :  the  private  part  of  the  specification  and  the  package 
body  are  missing.  The  design  of  PrettyPrint  described  herein  is  specified  by 
using  Ada  as  a  Program  Design  Language.2  with  the  Intention  that  the  Implemen¬ 
tation  will  be  written  In  Ada  using  that  package. 

The  designers  of  the  Olana  package  provided  two  distinct  methods  for  travers¬ 
ing  Diana  structures.  As  a  deliberate  policy,  this  design  uses  both  such  ways  so 
as  to  Insure  that  both  are  properly  designed  and  adequate  for  the  purpose. 

•  The  first  tree  walk.  WALK1 .  uses  the  general  tree  traversing  opera¬ 

tions:  ARITY.  SON1 .  ate.  The  function  ARITY  applied  to  a  Diana 
node  returns  the  structure  of  the  node,  which  is  (essentially)  the 
number  of  offspring  of  the  node.  The  SONfc  subprograms  then 

provide  access  to  the  relevant  offspring.  These  operations  permit  a 
program  to  traverse  a  tree  structure  without  taking  specific  cognizance 
of  the  nature  (other  than  number  of  offspring)  of  each  node 
traversed. 

•  The  second  tree  walk.  WALK2.  uses  the  attribute-specific  operations 
such  as  AS^ACTUAL.  AS^ALIQNMENT.  ate.  In  this  method,  on 
reaching  a  node  one  must  determine  (with  function  KIND )  the  nature 
of  the  node,  and  then  use  the  appropriate  attribute-accessing  func¬ 
tions  to  explore  the  children. 

The  intent  has  been  to  test  the  adequacy  of  the  design  of  package  Diana. 


*TMs  vm  of  Ada  as  «  Program  Design  Language  (PIX)  is  discussed  in  Section  1.4.4  on  page  23. 
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As  it  turns  out.  we  found  It  appropriate  for  this  project  to  augment  Diana.  In  a 
manner  anticipated  in  the  ORM.  Thus  the  package  used  here  is  PPjDlana. 
rather  than  Diana  of  Chapter  4  of  the  DRM.  See  Section  1.2. 2. 3  on  page 
12  of  this  document  for  details  of  what  was  done  and  why. 

1 . 2.  Design  Overview 

We  have  found  it  convenient  to  think  separately  about  two  aspects  of  pretty¬ 
printing:  raconatructlon .  and  formatting.  The  first  aspect  involves  reconstructing 
the  characters  that  make  up  the  source  text,  without  concern  for  how  the 
characters  are  to  be  laid  out  on  the  page;  the  second  aspect  involves  making  all 
decisions  concerning  page  layout  and  then  carrying  them  out.  Although  this 
distinction  Is  often  useful  In  the  discussions  in  this  document.  It  turns  out  that  It 
is  not  very  apparent  in  the  code  itself,  whose  modularity  is  designed  from  a 
different  viewpoint. 

All  of  PrettyPrint's  work  Is  performed  by  the  three  ma|or  modules  of  the 
program:  WALK1 .  WALK2.  and  FORMAT,  described  briefly  in  the  following  sub¬ 
sections  and  then  In  more  detail  in  the  rest  of  this  report.  Part  of  the  structure 
of  the  so-called  ‘main  program*  and  the  specification  parts  of  modules  WALKf 
and  WA LK2  are  shown  In  Figure  1-1  on  page  8:  the  specification  of  FORMAT  is 
in  Figure  1-4  on  page  16.  The  modules  are  listed  In  the  order  In  which  they 
are  discussed  in  this  chapter;  of  course,  they  would  have  to  be  presented  to  an 
Ada  compiler  In  a  different  order. 

Entries  in  the  package  PPJDIana  are  used  tor  all  accessing  of  the  Diana 
structure;  this  package  is  described  In  Section  1.2.2  on  page  9. 

1.2.1.  The  Main  Program 

For  the  sake  of  convenience,  we  have  assumed  a  main  program,  here  the 
procedure  Main,  which  is  called  somehow  by  ‘the  operating  system*,  a  concept 
not  further  discussed.  We  show  only  that  part  of  Main  that  calls  the  routines 
that  perform  pretty-printing. 

We  assume  that  a  specific  Instance  of  a  Diana  structure  Is  specified  as  being 
the  one  to  be  pretty-printed,  again  via  some  means  not  here  discussed.  The 
otherwise-unspecified  function  Qat_PP_Traa  returns  this  structure.  It  is  important 
to  note  that  the  program  as  written  assumes  that  the  tree  returned  Is  one  whose 
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—  Main  program.  Assume  that  this  is  called  by  "the  operating  systee”. 

with  OetJPP_Tree;  use  Ost_PP_Tree;  —  function  that  reads  PP_Diana 

with  pp_ptana;  use  PP_Diana>  —  DIANA  package,  for  pretty  printing 

with  MMJCL,  NALK2;  —  routines  to  walk  the  trees 

proasdure  Main  is  —  sain  progras 

T«  TREE;  —  DIANA  tree  to  be  pretty-printed 

begin 

—  Negotiate  with  user  to  determine  specific  tree  to  be  printed. 

T  i«  Get_PP_Tree<  ...);  —  The  tree  to  be  printed  is  in  T. 

MUUCl.NAZJCl(T);  —  perform  first  walk 

MUUa.WUK2(T);  —  perform  second  walk 

end  Main; 


—  Package  to  perform  the  first  walk  over  the  tree. 

with  PP_Diana;  use  PP_piana>  —  DIANA  package,  for  pretty  printing 

package  nauu.  is 

procedure  WALK1(T:  in  out  TREE); 

Sad  NAUCl; 


—  Package  to  perform  the  second  walk  over  the  tree. 

with  pp_piana;  use  PPJDiana;  —  DIANA  package,  for  pretty  printing 

NAUC2  is 

procedure  NAUC2(T:  is  TREE); 
end  WAUC2; 

Figure  1-1:  Top  Level  Ada  Modules 


< 


t 
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typo  Is  PP_Qlana.  Traa,  and  not  Diana.  Traa9.  Thoro  aro  of  course  other  pos¬ 
sibilities  for  acquiring  the  program's  input,  such  as  the  following: 

•  The  program  could  acquire  (somehow)  a  structure  of  type  Diana.  Traa 
rather  than  PP^piana.Traa.  and  than  Invoka  a  suitable  subprogram  to 
transform  It  to  tha  desired  type. 

•  If  the  Diana  structure  to  be  pretty-printed  exists  In  Diana  external  form, 
the  Diana  reader  that  transforms  external  Diana  Into  internal  might  be 
modified  to  create  the  additional  attributes,  though  without  values. 

•  WALK1  could  be  reformulated  to  take  an  In  argument  of  type 
Diana.  Tram  and  produce  an  out  argument  of  type  PPJitana.  Tram. 

We  do  not  pursue  this  point  further  as  It  is  not  relevant  to  the  purpose  of  tho 
project. 

Procedure  WALK1  is  called  with  one  argument:  a  tree  of  type  PP_J)lana.Traa. 
it  walks  over  that  structure  and  modifies  It.  calculating  and  storing  values  for 
certain  attributes  specific  to  pretty-printing. 

Next  procedure  WA LK2  walks  over  the  resulting  tree,  emitting  the  desired 
output  as  It  goes.  It  calls  entries  In  package  FORMAT  to  perform  storing  of 
output.  All  formatting  decisions  are  made  In  WALK2. 

1.2.2.  The  Diana  Structure 

As  suggested  above,  the  Input  to  the  program  Is  not  an  object  of  type 
Dlana.Traa  but  rather  one  of  type  PPJDIana.  Traa.  The  distinction  between  these 
is  now  presented.  Section  1.2.2. 1  describes  first  the  Ada  package  Diana,  the 
package  described  in  Chapter  4  of  the  DRM.  Next  Section  1.2. 2. 2  addresses 
the  issues  involved  in  using  IOL  to  describe  a  new  structure  In  terms  of  one 
already  defined.  Finally.  In  Section  1.2. 2. 3  the  special  version  of  Diana 
relevant  to  pretty-printing  Is  presented. 

1 . 2. 2. 1 .  The  Package  Diana 

Chapter  4  of  the  DRM  provides  the  specification  part  of  an  Ada  package  that 
provides  access  to  a  concrete  representation  of  Diana.  Omitting  most  details,  a 
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|  sketch  of  the  packaga  is  shown  In  Pigura  1-2  on  paga  II4.  It  daftnas  and 

makas  aval  labia  tha  following  namas: 

typo  TREE  An  ob|act  of  this  privata  typo  is  a  nods  of  tha  Diana 

structura. 

typo  SEQ_TYPE  An  objact  of  this  privata  typa  is  a  sequence  of  nodas  of  tha 
same  class. 

typa  NOOE_NAME  This  Is  an  anumaratlon  typo  providing  an  anumaratlon  literal 
for  each  kind  of  Diana  node. 

function  MAKE  This  function  creates  and  returns  a  Diana  node  of  tha  kind 
which  Is  Its  argument.  Note  that  it  is  overloaded  so  as 

also  to  be  able  to  create  an  empty  list. 

procedure  DESTROY 

This  procedure  Indicates  that  a  node  Is  no  longer  required. 

Given  a  node,  this  function  returns  its  node-kind. 

This  enumeration  type  provides  a  literal  for  each  number  of 
structural  children  a  node  might  have. 

M. 

For  k  =»  1.  2.  3.  each  such  function  returns  the  k 

offspring  of  a  node. 

For  k  *  1.  2.  3.  each  such  procedure  stores  a  new  k * 
offspring  of  the  node. 

A  collection  of  functions  and  procedures  Implement  the 
usual  list-processing  primitives. 

For  each  possible  attribute,  there  Is  a  function  to  return  the 
value  of  that  attribute  at  a  node,  and  a  procedure  to  store 
a  new  value  for  the  attribute. 

Although  subprograms  MAKE  and  DESTROY  Just  listed  and  subprograms  INSERT 
and  APPEND  mentioned  In  Figure  1-2  are  not  used  by  program  PrettyPrint.  for 
completeness  they  are  listed  In  this  discussion. 


function  KINO 
type  ARITIES 

function  SONk 

procedure  SONk 

list  processing 

attributes 


i 

1 


4Por  the  take  of  oompletanaaa,  the  paokaaa  Hate  several  subprogram#  that  are  not  used  by 
PiettyPMnt.  Such  subprograms  are  MAKE  (wMan  appears  twice,  overloaded),  DESTROY,  INSERT,  and 
AFFENO. 


* - 


V 
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psrtrsgs  Diana  is 

typo  Troo  la  private; 
typo  SBQ—TXPE  is  private; 

typo  NOOejKMB  is 

<  ... 

)» 

—  Troo  oonstructoro. 
function  MAKE  (Cl  in  NOQE_NAME)  rotuzn  TREE; 

pcoOOdUBO  DESTROY  (ti  in  TREE); 

function  KIND  (ti  in  TREE)  return  NODE_NAMEj 

—  Troo  traversers  from  the  Ada  Formal  Definition. 


—  a  Diana  node 

—  sequence  of  nodes 

—  enuaoration  class  for  node  names 

—  about  160  different  node  types 


type  ARITIES  is  (nullary,  unary,  binary,  ternary,  arbitrary); 


(ti 

(t« 

(t* 

(ti 

<t» 

(ti 

(ti 


in  TREE) 
in  TREE) 
in  out  TREE; 
in  TREE ) 
in  out  TREE; 
in  TREE) 
in  out  TREE; 


v» 


VI 


VI 


return  ARITIES; 
return  TREE; 
in  TREE); 

return  TREE; 
in  TREE); 

return  TREE; 
in  TREE); 


function  ARITY 
function  SON1 
procedure  SOMl 
function  30M2 
procedure  S0M2 
function  SON3 
procedure  S0M3 

—  Handling  of  list  constructs . 
function  HEAD  (It  in  SB&_TYPE) 

function  TAIL  (It  in  SEQ_TYPE) 

function  MAKE 

function  I3_EMPTY  (It  in  SEft_TYPE) 
function  INSERT  (It  in  cut  SEQ_TYPE; 

it  In  TREE) 

function  APPEND  (It  in  out  SEQJTTPE; 

it  in  TREE) 


return  TREE;  —  lisp  car 

return  seq_tyfe;  —  lisp  cdr 
return  SEQ_TfPE; 

—  return  anpty  list 
return  BOOLEAN; 

return  seq_tcte; 

—  inserts  i  at  start  of  1 

return  sbQ-TTPE; 

—  inserts  i  at  end  of  1 


—  Handling  of  LIST  attribute  of  list  constructs. 
procedure  LIST  (ti  in  out  TREE;  vi  in  SEQ_TXPE); 
function  list  (ti  in  TREE)  return  seqjwpe; 


—  Structural  Attributes. 


procedure  ASJtCRAL  ( t *  in  cut  TREE;  vi  in  TREE); 

function  A8_RCTUAL  ( 1 1  in  TREE )  return  TREE  ;  —  assoc 

•  4  • 

—  followed  by  functions  and  procedures  for  about  100  attributes  . 

privets 

—  To  be  filled  in... 


end  Diana; 


Figure  1-2:  Sketch  of  the  Diana  Package 
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1.2.2. 2.  IOL  and  Refinements 

Diana  la  daflnad  In  a  notation  callad  IDL  14).  a  notation  daalgnad  expressly  for 
daacribing  structuras  to  b*  used  as  Intarfacas  batwaan  softwara  componants. 
Tha  daslgnars  of  IOL  foresaw  that  users  of  an  abstract  type  (such  as  Diana) 
might  require  another  abstract  type  that  was  almost  tha  same  as  tha  first,  but 
slightly  different.  IOL  therefor*  provides  the  concepts  of  raflnomont  and  deriva¬ 
tion.  methods  for  defining  such  a  structure  by  listing  only  the  differences  from 
some  already  defined  IOL  structure. 

Details  about  refinements  and  derivations  are  to  be  found  In  Section  2.3  of 
the  IOL  Reference  Manual  (4).  However,  enough  Information  about  the  concept 
for  present  purposes  may  be  found  in  Appendix  II  of  the  DRM.  In  which  the 
Abstract  Parse  Tree  (APT)  Is  defined  by  derivation  from  the  Diana  structure. 
Derivation  Is  a  more  general  process  than  the  refinement  used  here,  as  deriva¬ 
tion  permits  both  additions  and  deletions  whereas  refinement  permits  only 
additions. 

1.2. 2. 3.  The  Package  PP_piana 

For  the  purposes  of  the  design  of  PneTTYPWNT.  It  Is  useful  to  have  three 
additional  attributes  at  some  of  the  nodes.  These  provide  a  place  to  record 
data  gathered  during  the  first  tree  walk  so  that  they  are  available  during  the 
second. 


In  the  present  case,  we  define  a  new  abstraction.  PP^Qlana.  by  refinement 
of  Diana.  This  new  type  Is  Ilk*  DIANA  but  has  added  to  It  three  new  attributes, 
listed  below.  Then  the  Ada  package  PPJJIana  Is  Just  like  the  Ada  package  Diana 
except  that  the  enumeration  type  NODEJ'iAM E  contains  three  new  names  and 
there  are  three  new  functions  and  three  new  procedures  to  deal  with  the  new 
attributes. 

The  three  new  attributes  are  as  follows: 

pp_ohara  This  attribute  holds  the  number  of  characters  required  to 

print  the  complete  ADA  structure  at  the  nod*  and  Its  des¬ 
cendants.  The  computation  Ignores  ail  considerations  of 
formatting,  assuming  that  all  the  code  fits  on  on*  line  and 
that  lexemes  are  separated  (when  necessary)  by  a  single 
space. 


pp_fnax_phara  Present  on  any  nod*  that  Is  a  list,  this  attribute  holds  the 
maximum  number  of  characters  required  to  print  any  ele¬ 
ment  of  the  list.  The  calculation  follows  the  same  conven- 
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tlons  as  for  pp_jshara. 

ppjndant  This  attribute  holds  the  total  number  of  extra  Indentation 

levels  required  to  print  this  node.  For  all  leafs  the  value  is 
zero.  For  a  procedure  body,  for  example,  it  Is  one 
greater  than  the  maximum  required  for  any  declaration, 
statement,  or  exception  In  the  body. 

A  complete  listing  of  the  refinement  that  specifies  PP_0/ana  is  In  Appendix  C. 

1.2.3.  The  Package  WALF1 

Note  from  Figure  1-1  on  page  8  that  the  package  I NALK1  makes  available 
externally  only  a  single  procedure,  also  named  WALK1 .  This  procedure  walks 
over  the  structure  that  Is  Its  Input,  calculating  and  storing  values  for  the  three 
attributes  that  are  needed  by  Pretty  Prjnt.  as  described  In  the  preceding  section. 
The  process  is  described  in  detail  In  Section  4. 2  on  page  66. 

It  computes  and  stores  at  each  node  the  indentation  level  required  to  print 
that  node,  based  (essentially)  on  the  nesting  depth  of  such  Ada  control  struc¬ 
tures  as  packages  and  procedures  and  compound  statements  whose  bodies  are 
Indented  from  the  surrounding  text. 

It  computes  and  stores  at  each  node  the  number  of  characters  required  to 
print  the  node,  ignoring  formatting  requirements.  These  data  are  needed  for  the 
second  pass  over  the  tree  producing  output. 

For  each  sequence  node  (i.e. .  a  Diana  ‘Seq  of*  node).  It  computes  and 
stores  the  maximum  number  of  characters  required  by  any  element  of  the 
sequence. 

The  body  of  WALK1 .  considered  In  detail  in  Section  4.2  on  page  68.  consists 
of  first  some  declarations  of  Interest,  then  functions  and  procedures  to  do  the 
work,  and  finally  the  body  of  procedure  WA LKi.  A  sketch  of  the  package  body 
for  WA  LKI  Is  In  Figure  1-3  on  page  14.  The  pass  walks  the  tree  using  the 
general  tree  traversing  operations  of  the  package  PP_PiANA. 

1.2.4.  The  Package  WALKZ 

Package  WALK2.  like  peckage  WALK1 .  exports  only  a  single  procedure. 
Again.  It  Is  a  procedure  that  performs  a  single  walk  over  the  structure.  Proce¬ 
dure  WALK2  walks  over  the  tree,  calling  entries  In  package  FORMAT  to  perform 
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—  Package  to  per£or*  the  first  walk  over  the  tree, 
parlraga  body  NALKl  is 

3on_Count  t  ARXTIES  range  unary  . .  ternary; 

Meet  i  constant  array  <NOOS_NAKE,Son_Count:)  of  NATURAL 
«•  (  •••  )> 

Char  t  constant  array  (NOOEJNAME)  of  natural 

i-  <  ..  )/ 

function  Max(Xi  In  NATURAL;  Y:  in  NATURAL) 
returns  natural  is  separate; 

procedure  Li*tNal)c( Node  i  in  out  TREE; 

Depth  <  out  NATURAL; 

Length  i  out  NATURAL; 

MsxLength  i  out  NATURAL); 

procedure  NodeWaUc(Node  i  in  out  TREE; 

Depth  t  OUt  NATURAL; 

Length  I  out  NATURAL); 

procedure  HalXi(T:  in  out  TREE)  is  separate; 

procedure  Lie twaOJc(  Node  >  in  out  TREE; 

Depth  t  out  NATURAL; 

Length  i  out  NATURAL; 

KaxLength  t  out  NATURAL)  is  separate; 

procedure  KodeNalJc<Node  i  in  out  TREE; 

Depth  t  out  NATURAL; 

Length  :  out  NATURAL)  is  separate; 


Od  NKUU; 


Figure  1-3:  Outline  of  Package  Body  WALK1 

output.  All  formatting  decisions  are  made  In  WALKS. 

The  structure  of  WALKS  Is  similar  to  that  of  WALK1 ,  although  there  are  many 
more  functions  and  routines.  It  Includes  the  line 

With  FORMAT;  UM  FORMAT; 

to  provide  access  to  the  subprograms  in  package  FORMAT  that  Interface  to  the 
output.  This  pass,  unlike  the  previous  one.  uses  the  specific  attribute  accessing 
operations  from  package  PP JUANA  to  traverse  the  tree. 


Details  about  this  process  are  found  In  Section  4.3  on  page  78. 
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1.2.5.  The  Package  FORMAT 

The  formatting  decisions  made  In  WALK2  are  Implemented  by  calling  entries  in 
package  FORMAT.  The  specification  of  package  FORMAt  Is  In  Figure  1-4  on 
page  16.  Typical  formatting  decisions  Include  when  to  break  a  line,  how  many 
spaces  to  Indent  a  new  line,  and  so  on. 

FORMAT  maintains  a  buffer  Into  which  to  collect  together  a  line  of  characters 
for  outputting. 

Because  line  indentation  Is  such  an  important  concept  in  pretty-printing. 
FORMAT  provides  considerable  services  for  it.  It  maintains  a  stack  of  Inden¬ 
tations.  and  at  any  moment  each  line  produced  Is  indented  by  the  number  of 
spaces  shown  at  the  top  of  the  stack.  Entering  a  program  area  (such  as  a 
procedure  body)  requiring  additional  Indentation  Implies  pushing  a  new  entry  onto 
the  stack,  using  the  procedure  Indent:  leaving  such  a  scope  requires  calling 
Undent  to  pop  the  stack. 

The  indentation  stack  is  used  also  to  deal  with  overflow  lines.  For  example, 
suppose  a  statement  Is  about  to  be  printed  which  cannot  fit  on  the  line.  (Code 
In  WALK2  knows  how  much  space  Is  required  to  print  the  statement  from  the 
ppjBhara  attribute  on  the  statement  node,  and  it  knows  how  much  space  remains 
on  the  line  by  calling  function  Remaining  In  FORMAT. )  In  such  a  case  the 
FORMAT  entry  Setlndent  is  called  to  set  Indentation  as  appropriate  for  the  extra 
characters  of  the  statement. 

With  this  background  In  mind,  here  Is  a  brief  description  of  each  external 
entry  Into  package  FORMAT.  The  term  Indentation  constant  refers  to  the  fixed 
amount  each  nested  region  of  text  Is  Indented  beyond  the  surrounding  region. 

constant  UneLength 

This  Is  the  number  of  characters  In  the  output  line. 

type  Column  An  object  of  this  type  Is  an  integer  between  zero  and 
UneLength . 

function  Position  This  function  returns  the  position  on  the  line  of  the  next 
character  to  be  stored. 

function  Remaining 

This  function  returns  the  number  of  available  characters  on 
the  line.  (It  Is  always  UneLength  -  Position .) 
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—  Package  that  provides  operations  to  format  reconstructed  Ada  source 
package  FORMAT  is 
Linebength  t 

constant  POSITIVE  «■  120 ;  — •  length  of  the  output  line 

type  Column  is 

range  0. .Line Length)  —  position  on  the  line 

—  there  are  four  procedures  to  append  text  to  the  output  buffer 
procedure  AddText( Text  1  in  String)) 

procedure  ResForm  —  add  Ada  reserved  words 

(Texti  In  string)) 

procedure  Conform  —  add  comments 

(Text)  in  string)) 

procedure  Identform  —  add  program  identifiers 

(Textt  in  String)) 

—  There  are  two  function  to  return  status  of  the  output  buffer 

function  Remaining  return  Column)  —  unused  characters  in  buffer 
function  Position  return  Column)  —  used  characters  in  buffer 

—  this  procedure  creates  a  line  break 
procedure  NewLine; 

—  this  procedure  sets  the  indentation  increment 
procedure  Setlncrement( Depth »  in  POSITIVE)) 

—  three  procedures  provide  indentation  operations 

procedure  Indent)  —  increment  from  last  indentation 

procedure  Undent)  —  revert  to  previous  indentation 

procedure  3etIndent(Pos<  in  Column)) 

—  set  indentation  to  Poe 

end  FORMAT) 


Figure  1-4:  Package  FORMAT  Specification 
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procedure  Indent 

This  procedure  pushes  onto  the  Indentation  stack  the  next 
standard  Indentation.  That  Is.  It  pushes  a  number  that 
exceeds  the  last  entry  by  the  Indentation  constant. 

procedure  Setlndent 

This  procedure  pushes  Its  argument  onto  the  Indentation 
stack. 

procedure  Undent 

This  procedure  pops  the  Indentation  stack,  restoring  the 
Indentation  to  the  previous  value. 

procedure  NewLine 

This  procedure  finishes  the  current  line  and  outputs  It.  and 
then  stores  the  Indentation  for  the  next  line. 

procedure  AddText 

This  procedure  is  used  to  store  text  Into  the  output, 
procedure  ResForm 

This  procedure  Is  used  to  store  a  reserved  word  into  the 
output.  It  formats  the  word  as  appropriate.  For  example, 
reserved  words  might  (as  in  this  document)  be  printed  with 
boldface  type. 

procedure  ComForm 

This  procedure  Is  used  to  store  comments  Into  the  output, 
formatting  words  as  appropriate.  For  example,  comments 
might  be  printed  with  Italic  type. 

procedure  IdentForm 

This  procedure  Is  used  to  store  a  programmer  Identifier  Into 
the  output. 


1.3.  Observations  about  DIANA 

In  this  section  we  record  some  observations  we  have  made  about  Diana  during 
the  course  of  this  design.  It  is  these  comments  that  are  the  principal  output 
from  this  study.  With  the  exception  of  the  point  raised  In  the  next  subsection 
concerning  Diana's  handling  of  Aoa  comments,  we  have  concluded  that  Diana's 
design,  as  stressed  by  the  design  of  PrettyPrint,  Is  adequate. 
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1.3.1.  Handling  Aoa  Comments 

The  design  of  PrettyPrint  has  revealed  a  serious  problem  In  Diana's  handling 
of  comments  In  the  Aoa  text.  Obviously  this  problem  Is  of  no  concern  to  writers 
of  compilers  and  most  other  tools  In  APSE,  since  It  atlects  only  tools  which  are 
concerned  with  the  exact  placement  of  comments  In  Aoa  source  text.  Nonethe¬ 
less.  It  Is  a  problem  which  requires  a  solution. 

The  problem  Is  that  there  Is  not  an  adequate  way  to  determine  the  correct 
piece  of  Aoa  source  text  with  which  to  associate  a  comment.  It  Is  instructive  to 
note  how  this  problem  arose  in  our  design  effort.  As  outlined  in  Section 
3.1.4  on  page  47.  PrettyPrint's  handling  of  comments  Is  rather  poor.  At  first 
we  felt  that  we  were  doing  poorly  because  we  had  given  the  problem  Inadequate 

5 

attention  .  However,  on  further  reflection  we  realized  that  PrettyPrint  cannot 
possibly  put  the  comments  'where  they  belong'  because  It  has  no  way  of 
knowing  where  In  fact  they  do  belong. 

To  a  first  approximation,  the  problem  Is  that  PrettyPrint  has  no  way  to  know 
how  the  creator  of  the  Diana  placed  the  comments.  However,  the  real  problem 
is  that  there  exist  no  comment-placement  standards  to  be  obeyed  by  Diana 
creators.  Even  more  seriously,  there  are  sensible  places  In  Ada  text  at  which  to 
place  comments  for  which  there  Is  no  Diana  node  to  which  to  attach  the 
comment. 

To  see  these  problems,  consider  the  following  example  of  Ada  code.  The 
Ada  code  was  copied  directly  from  one  of  the  examples  In  Section  6.  1  of  the 
Ada  LRM  and  then  reformatted  and  commented  to  make  several  points: 

procedure  —  [l]  Print  a  header. 

PRINT__HEAOER  —  [2]  It  is  called  whenever  ... 

<  —  [3]  Its  parameter*  are  ... 

PAQES  t  in  NATURAL ;  —  [4]  number  of  pages 

HEADER  *  in  LINE  —  [5]  the  line  to  print 

!-  (1.  .LINE’LAST 

CENTER «  in  BOOLEAN  —  [6]  center  it? 

«-  TRUE 

)> 

(The  numbers  In  [. .  ]  serve  to  Identify  the  comments  in  the  following 
discussion.)  Ideally,  it  should  be  possible  for  the  compiler  Front  End  (or  other 
Diana  creator)  to  leave  enough  information  In  the  tree  so  that  It  would  be 


®lt  la  oompleteiy  consistent  with  our  design  goals  ss  described  In  Section  1.1  on  page  5  to  give  tittle 
attention  to  such  e  problem. 
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possible  tor  a  program  like  PrettyPrint  to  recreate  this  program  as  here 
displayed.  For  some  of  the  comments,  such  as  [4].  [51  and  (61.  there  is  no 
problem  In  doing  so — the  comment  could  be  the  value  of  the  /x_commenf  at¬ 
tribute  on  the  In  node  that  Is  the  formal  parameter.  However.  It  does  not 
appear  possible  to  find  two  different  places  In  the  structure  for  comments  (21  and 
(3).  Also.  PrettyPrint  could  not  possibly  know  how  to  place  comment  [1]  unless 
It  was  aware  of  the  conventions  used  In  creating  the  Diana. 

Although  this  example  Is  perhaps  slightly  contrived,  it  suggests  a  real 
problem.  First,  there  exist  programmers  who  might  well  write  comments  In  the 
style  suggested  here.  Such  a  programmer  who  went  to  the  trouble  to  Insert 
these  comments  would  be  properly  dismayed  to  discover  that  they  were  unsatis¬ 
factorily  rearranged  by  tools  in  an  APSE.  Second,  however,  and  much  more 
serious,  tools  are  coming  Into  existence  which  care  very  much  how  comments 
are  arranged. 

One  such  tool  Is  ANNA  [31.  a  tool  which  permits  a  user  to  decorate  an  Aoa 
program  with  annotations  which  are  recognized  by  an  ANNA  processor.  Syntac¬ 
tically.  all  such  annotations  are  Ada  comments  and  would  be  ignored  by  any 
conforming  Ada  compiler.  However,  an  ANNA  processor  takes  cognizance  of 
comments  starting  with  ' — :*  or  '  —  I*.  Interpreting  them  as  Input  for  certain 
kinds  of  program  analysis.  Further  details  are  not  relevant  here. 

Although  one  could  design  an  ANNA  processor  to  take  Ada  text  as  its  input, 
such  an  approach  Is  Inconsistent  with  AJPO’s  Intent  for  tools  In  an  APSE.  It  is 
much  more  appropriate  for  the  tool  to  use  Instead  a  Diana  representation  of  an 
AOA  program.  However,  because  the  placement  of  the  special  comments  has 
semantic  implications  for  ANNA,  it  could  do  so  only  if  it  were  possible  to  derive 
from  the  Diana  the  original  placement  of  Aoa  comments  In  the  source  program. 
For  such  a  tool  to  be  transportable  from  one  APSE  to  another  with  a  different 
AOA-to-OiANA  transformer.  It  Is  necessary  that  the  DRM  specify  adequately  the 
details  of  placement  of  Ada  comments  In  the  Diana  tree. 

Although  our  analysis  of  this  problem  In  connection  with  building  PrettyPrint 
suggests  that  further  Diana  design  In  connection  with  Ada  comments  Is  desirable. 
the  problems  faced  by  the  builder  of  a  tool  such  as  ANNA  suggest  that  such 
redesign  Is  required.  As  Ada  matures  and  sophisticated  tools  of  the  type 
suggested  by  ANNA  become  available  for  Inclusion  in  APSEs.  it  will  become  more 
and  more  necessary  to  address  and  solve  this  problem. 
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1.3.2.  Oiana  Normalizations 

The  Diana  Reference  Manual,  following  the  lead  of  the  Ada  Formal  Definition, 
uses  the  term  normalization  to  refer  to  certain  arbitrary  decisions  made  in 
constructing  the  Diana  representation  that  are.  In  effect,  losses  of  Information. 
For  example,  one  may  elect  to  Ignore  case  distinctions  In  the  spelling  of 
reserved  words  and  program  Identifiers.  Some  of  these  normalizations  have  an 
impact  on  source  reconstruction.  In  the  DRM.  this  topic  Is  Introduced  In  Section 
3.1.3  and  then  discussed  at  greater  length  In  Appendix  III.  Section  3.  The 
present  discussion  is  keyed  to  the  latter. 

Ada  permits  an  optional  Identifier  following  the  reserved  word  end  In  certain 
contexts,  such  as  a  block  body,  subprogram  body,  and  so  on;  If  the  Identifier  Is 
present.  It  must  match  an  Identifier  at  the  beginning  of  tiie  context.  As  there  is 

no  provision  In  Diana  for  recording  whether  or  not  this  identifier  Is  present,  a 

program  such  as  PnemrPRiNr  that  does  source  reconstruction  must  either  always 
Include  the  labels  or  always  omit  them.  We  have  chosen  to  Include  them. 

In  formal  parameter  declarations  for  subprograms,  the  mode  in  Is  optional 
and  Is  not  recorded  In  the  Diana.  We  have  chosen  always  to  include  It. 

Diana  does  not  require  that  extra  spaces  between  lexical  tokens  be  preserved. 

Variant  spelling  of  an  identifier,  as  for  example  *FOO*  and  'Foo*  and  *foo*. 

need  not  be  recorded  in  Diana. 

Alternate  writings  of  numeric  constants  need  not  be  preserved.  For  example. 
In 

2  002  0_0_2 

2#1111_1111#  16iFT*  016#0m  25S 

1201  1.282  0.128+3  01.2802 

all  the  values  on  each  line  are  represented  identically  In  the  Diana  and  so  are 
reconstructed  Identically.  This  Issue  is  essentially  the  same  as  the  variant 
spelling  of  Identifiers;  Diana  does  not  require  that  variations  be  preserved. 

One  normalization  present  in  Ada-80  Is  absent  In  Aoa-82.  the  distinction 
between  an  infix  and  prefix  form  of  an  operator.  For  example.  In  the  earlier 
version  of  Diana  based  on  AOA-80.  each  of 

...  A  +  B  ... 

...  "+"(  A,  B)  ... 

Is  represented  by  the  same  structure.  However,  the  conformance  rules  of 
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Ada-82  as  expressed  In  Section  6.3.1  of  the  Ada  LRM  require  that  the  distinction 
be  preserved.  For  this  reason,  Diana  now  has  the  boolean  attribute  sm^preflx  to 
record  which  was  used.  See  Section  3.3.4  of  the  DRM. 

1.3.3.  Diana  Problem  Areas 

Although  Diana  was  designed  to  preserve  the  structure  of  the  original  source 
program,  and  Indeed  the  design  of  PRemPRiNT  shows  that  the  structure  Is  In  fact 
preserved,  we  discovered  that  there  are  some  Diana  nodes  that  present  special 
problems.  Generally,  these  are  nodes  where  the  source  to  be  reconstructed 
cannot  be  determined  without  knowing  the  context  In  which  the  node  appears. 

Attribute  When  an  attribute6  appears  as  the  description  of  the  range 

in  a  range  constraint,  the  attribute  should  be  preceded  by 
the  Ada  reserved  word  ‘range*:  in  all  other  cases  the 
attribute  appears  by  itself. 

Id_s  When  a  sequence  of  Identifiers  Is  the  list  of  labels  before  a 

statement,  each  Identifier  should  be  surrounded  by  the  spe¬ 
cial  brackets  '«  »'  and  commas  should  not  appear  between 
the  Identifiers:  In  all  other  cases  the  identifiers  appear 
without  any  bracketing  and  are  separated  by  commas. 

Task  Type  When  a  type  declaration  defines  a  task  type,  the  Ada 

reserved  word  ‘type*  should  be  preceded  by  the  Ada 
reserved  word  ‘task*:  in  all  other  cases  there  Is  no  text 
precoding  it. 

Header  When  constructing  the  text  for  nodes  In  the  class  HEADER. 

which  corresponds  to  the  header  part  of  a  function  or 
procedure  declaration,  it  Is  necessary  to  have  the  name  of 
the  subprogram,  so  that  it  can  be  printed  in  the  decla¬ 
ration.  The  Identifier  must  be  passed  down  from  the  parent 
node. 

Loop  and  Block  When  loop  or  block  appear  as  the  child  of  a  named_stm 
node  (that  Is.  a  loop_ldentlfler  or  block_ldentlfler  has  been 
specified) .  then  the  identifier  must  appear  again  after  the 
ADA  reserved  word  ‘end*  and  before  the  semicolon.  The 
Identifier  must  be  passed  down  from  the  parent  node.  In 
all  other  cases  no  Identifier  appears  after  ‘end*,  and  there 
Is  no  Identifier  to  be  passed  from  a  parent  node. 


®ln  thie  content,  the  term  attribute  refers  to  an  Ada  attribute  (auoh  aa  TWST) ,  and  not  an  attribute 
of  a  node  In  Diana. 
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Note  that  In  all  cases  just  discussed.  Information  needed  for  source 
reconstruction  is  not  found  exactly  where  it  Is  needed.  However.  In  all  cases  It 
Is  easy  to  code  WALK2  so  as  to  provide  the  Information.  Alternatively,  additional 
attributes  could  have  been  defined  where  needed  and  calculated  In  WALK1 . 
However,  the  essential  adequacy  of  Oiana  Is  shown  In  that  there  are  two 
straightforward  ways  to  deal  with  the  problem. 

1.4.  Comments  about  the  Design 

Here  are  some  observations  of  Interest  about  the  design. 

1.4.1.  Formatting  Decisions 

All  decisions  about  how  the  Ada  text  Is  to  be  formatted  are.  in  effect, 
‘hard-wired*  Into  the  code  of  WALK2.  Largely,  we  have  followed  the  lead  of  the 
Ada  LRM  In  deciding  how  to  display  Ada  code. 

Were  our  purpose  to  design  a  production  pretty-printer,  for  example  lor 
inclusion  in  an  APSE,  we  would  have  provided  an  Interface  to  let  the  user  (or  at 
least  the  local  system  malntainer)  to  parameterize  the  layout.  However,  such 
functionality,  though  clearly  desirable,  is  not  relevant  to  the  goals  of  the  project 
as  described  In  Section  1 . 1  on  page  5. 

1.4.2.  Assumptions  Made  In  the  Design 

We  have  made  certain  assumptions  In  the  design  of  PhettyPhint,  assumptions 
that  the  reader  should  be  aware  of. 

We  have  consistently  assumed  that  the  Diana  structure  supplied  is  correct. 
An  implementation  might  be  made  more  robust  by  the  addition  of  suitable 
checking. 

We  have  assumed  that  no  token  Is  longer  than  the  output  line.  It  Is  not 
clear  In  any  case  what  to  do  If  this  assumption  fails. 

We  have  assumed  that  the  nesting  of  the  underlying  program  is  not  ‘too 
deep*.  In  the  sense  that  excessive  Indentation  would  leave  not  enough  space  on 
a  line  for  meaningful  amounts  of  text.  (Although  the  program  does  not  fall  in 
any  unpleasant  way.  Its  treatment  of  the  situation  would  not  be  suitable  for  a 
production  environment.  See  the  discussion  of  procedure  Indent  In  Section 
3. 3. 2  on  page  58. ) 
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W*  hav*  assumed  that  characters  ar*  all  of  th*  sam*  width. 

We  have  assumed  the  existence  of  a  function  Length  that  determines  of  any 
token  (symbol,  number  or  operator)  the  number  of  characters  required  to  print 
It.  If  the  values  of  attributes  Ixjtymrep  and  lx_numrep  are  strings,  of  course, 
then  the  Implementation  of  Length  Is  quite  simple. 

1 . 4.  3.  Missing  Parts  of  the  Design 

Certain  parts  of  a  complete  pretty-printer  design  are  missing  from  this  docu¬ 
ment.  These  omissions  are  all  consistent  with  our  limited  goals  as  described  In 
Section  T.  1  and  are  recorded  here  merely  for  completeness. 

A  proper  pretty-printer  should  encapsulate  all  the  formatting  decisions  so  as 
to  permit  th*  user  (or  at  least  the  system  maintalner)  to  change  the  formatting 
decisions.  In  the  present  design,  all  such  decisions  are  embedded  In  the  code 
In  WALKf .  See  Section  1.4.1  on  page  22. 

PftErrrPmNT's  handling  of  comments  is  quite  weak.  This  fact  reveals  a 
problem  area  In  the  design  of  Diana,  discussed  in  Section  1.3.1  on  page  18. 

It  would  be  appropriate  to  recognize  certain  pragmas  that  control  listing,  such 

as 

pcaspas  list  j  —  turn  listing  on  or  off 

pmgpa  page;  —  eject  paper 
and  perhaps  others  of  our  own  design. 

Page  layout  Is  quite  weak.  Certain  structures  (such  as  subprograms)  should 
have  surrounding  white  space,  and  there  should  be  some  control  of  where  page 
breaks  occur. 

1 . 4. 4.  Ada  as  a  Program  Design  Language 

An  Interesting  recent  development  In  the  Aoa  world  has  been  the  use  of  Ada 
as  a  Program  Design  Language  ( POL) .  We  have  followed  the  lead  of  others  In 
doing  so.  As  the  technique  Is  not  yet  well  specified,  it  seems  In  order  to 
explain  |ust  what  w*  have  chosen  to  do. 

Aoa  by  the  nature  of  Its  design  separates  the  specification  of  a  program  from 
Its  definition  (which  In  Aoa  terms  Is  the  body) .  Taking  advantage  of  this 
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separation,  we  have  provided  complete  package  specifications  for  the  various 
modules  of  PncmPfttNT.  In  addition,  we  have  sketched  the  code  that  would  go 
Into  the  package  bodies,  with  no  attempt  to  provide  all  details.  Our  goal  has 
been  to  provide  adequate  detail  to  permit  an  Intelligent  implementor  to  complete 
the  Implementation. 

1 .  S.  Comments  about  this  Document 

The  remainder  of  this  document  specifies  In  detail  the  design  (but  not  the 
Implementation)  of  PftEmPniNT.  The  major  thrust  of  the  technical  presentation  Is 
In  the  next  three  chapters.  Chapter  2  presents  In  detail  the  Issues  Involved  In 
source  reconstruction.  Ignoring  temporarily  the  problem  of  formatting:  and  then 
Chapter  3  addresses  the  Issues  involved  in  Implementing  pleasing  formatting 
decisions.  Finally.  Chapter  4  shows  how  the  solutions  to  these  two  problems 
are  Implemented. 

Four  appendices  present  details  of  the  modules  that  carry  out  the  work. 
Appendices  A  and  B  discuss  the  two  tree  traverses,  which  are  carried  out  In 
packages  WALK!  and  WALK2.  respectively.  Appendix  C  discusses  the  changes 
required  In  the  Diana  structure  to  accommodate  the  needs  of  the  pretty-printing 
process.  Appendix  D  discusses  the  AOA  package  FORMAT  which  Implements  the 
formatting  processes. 

To  aid  the  reader,  consistent  typographic  conventions  are  adhered  to  In 
referring  to  oblects  and  syntactic  types  In  Ada  and  Diana.  The  conventions  are 
as  follows: 

Entity  Convention 

Ada  reserved  word  begin  end 

ADA  Identifier  FORMAT  TREEWALK 

Diana  classes  OBJECT J)EF  TYPE 

Oiana  nodes  constant  record 

Diana  attributes  Ixjircpoa  aa_obj9ct_dot 

Note  the  distinction  between  Diana,  the  name  of  the  abstract  data  type,  and 
Diana,  the  name  of  the  Ada  package. 

Because  we  cite  frequently  certain  literature  ratavant  to  Ada  and  Diana,  we 
use  consistently  following  abbreviations: 

ORM  The  DIANA  Reference  Manual.  (1). 


ADA  LRM 


The  Ada  Language  Reference  Manual.  [21. 
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IDL  Tho  IDL  Formal  Description,  [4). 

Not#  that  tho  vorsion  of  tho  DRM  cltod  la  tho  latoet  revision.  Thoro  aro  changes 
from  oarlior  revisions  that  aro  significant  to  this  document. 
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8QUACE  RECONSTRUCTION 


In  presenting  the  PflemPRtNT  design,  we  consider  separately  two  aspects  of 
pretty-printing:  source  reconstruction  and  formatting  of  the  reconstructed  source. 
Although  we  make  a  clear-cut  distinction  In  the  discussions  In  this  document,  the 
dichotomy  Is  blurred  In  the  completed  design,  but  is  nonetheless  present.  For 
the  purposes  of  analyzing  Oiana  In  a  new  application  domain,  source  reconstruc¬ 
tion  Is  the  more  Important  of  the  two  aspects. 

In  this  chapter  we  consider  only  the  requirements  for  reproducing  unformattad 
Ada  source.  The  formatting  Issues  involved  are  discussed  separately.  In  Chapter 
3  on  page  43.  The  complete  PRETTYPRiNr  design.  Incorporating  formatting  Into 
the  source  reconstruction.  Is  elaborated  In  Chapter  4  on  page  63. 

One  of  the  goals  of  the  Diana  design  is  the  ability  to  reconstruct  the  Ada 
source  used  to  create  an  Instance  of  Diana.  This  chapter  Illustrates  that  this 
goal  Is  met.  with  a  small  number  of  exceptions.  The  exceptions  are  normaliza¬ 
tions  that  are  necessary  during  reconstruction.  These  are  described  in  Section 
1.3.2  on  page  20. 

We  make  the  following  claim:  unformatted  Ada  source  can  be  reconstructed  In 
one  pass  over  the  Oiana  tree.  Furthermore,  with  one  exception,  the  only 
attributes  necessary  to  reconstruct  the  source  are  the  lexical  C/x_)  attributes, 
which  describe  the  representation  of  Identifiers,  operators,  and  numeric  literals; 
and  the  structural  <aa_)  attributes,  which  describe  the  structure  of  the  Diana 
tree. 

The  single  semantic  attribute,  sm^preflx.  Is  required  to  differentiate  between 
Infix  and  prefix  uses  of  operators.  This  distinction  Is  required  by  the  semantics 
of  Ada1.  Without  this  requirement,  the  form  of  all  operators  could  be  normalized 
and  source  could  be  reconstructed  without  any  semantic  attributes. 

The  reconstruction  pass  can  be  performed  with  a  simple  recursive  descent 
tree  walk.  In  general  the  text  at  a  node  is  generated  Independently  of  its 


1The  conformance  rules  for  default  formal  parameters.  Ads  CRN  Section  8.3.1  In  particular,  require 
tMs  distinction. 
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parents,  and  Includes  the  text  for  each  of  its  descendants  in  order  (the  few 
exceptions,  most  notably  subprogram_decls  and  task  types  are  described  In 
Section  2.2  on  page  32  below). 


2. 1 .  General  Treatment  of  Nodes 

In  this  section  we  show  how  pretty-printing  might  be  done  for  some  simpler 
language.  Our  purpose  Is  to  Illustrate  the  techniques  used  In  PrettyPrint  to 
pretty-print  ADA.  Suppose  the  Internal  form  of  this  simple  language  (analogous 
to  Diana)  has  two  types  of  nodes: 

Innar  nodes  with  structural  attributes:  In  Diana  the  only  lexical 

attributes  associated  with  these  nodes  are  lx_arcpoa.  source 
position,  and  lx_commenta.  the  comment  associated  with 
this  node. 

laaf  nodes  with  no  structural  attributes;  these  nodes  may  have  a 

lexical  attribute  of  Interest.  In  Diana  a  leaf  node  may  have 
the  attribute  lx_aymrap  or  lx_jtumrep.  or  may  have  no  at¬ 
tributes  at  all. 

The  canonical  Inner  node  has  one.  two.  or  three  descendants,  accessed  as 
structural  attributes.  The  IDL  representation  of  a  node  with  three  offspring  is 

Inner  «>  chlldl  «  TCStX, 

chlld2  :  TXPE2, 

ChlldS  i  TYPE3; 

To  further  the  analogy,  we  assume  the  existence  of  a  package  similar  to 
package  Diana  that  defines  a  type  TREE  such  that  leaf  and  Inner  nodes  belong 
to  the  type.  In  addition,  this  package  provides  functions  (‘operations*  on  type 
TREE)  that  provide  access  to  the  structural  attributes.  For  convenience  we 
name  the  functions  in  this  package  CHILD1.  CHILD2.  and  CHILD3.  Each  of 
these  functions  takes  one  argument,  a  node  of  type  TREE,  and  returns  a  node 
of  type  TREE  that  Is  the  corresponding  structural  attribute  of  the  node.  Using 
the  Ada  package  TEXT^JO.  as  described  In  Section  14.3  of  the  Ada  LRM.  the 
canonical  procedure  for  creating  the  source  associated  with  this  node  would  then 
be: 


J 


Source  Reconstruction 
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—  the  string  "Tex t/"  represents  an  arbitrary  text  string 

procedure  dp_lnner< Node t  in  TREE)  is 

begin 

put<  "TextO" )> 
dp_TTPEl( CHILD1(  Node ) ) } 

POT(  "Textl"  )> 
dp_TYPE2( CHIUD2(  Node ) ) ; 

P(JT(  "TSXt2"  ); 
dp_TYPE3(  CHILD3(  Node  )  ) » 

PUT<  "Text 3" )) 
end  dp_inner> 

The  procedures  dp_TYPE1 .  dpJTYPE2.  and  dp_TYPE3  are  procedures  that 
produce  the  text  for  nodes  of  the  IDL  type  TYPEl .  TYPE2.  and  TYPE3  respec¬ 
tively. 


In  other  words,  the  source  text  corresponding  to  any  node  is  merely  the 
correctly  ordered  concatenation  of  some  text  strings  inherent  to  the  node 
(‘TextO*.  ‘Textl*.  *Text2*.  and  *Text3‘)  and  the  source  text  for  its  descendants 
(the  text  produced  by  dpJTYPEI.  dp_TYPE2 .  and  dpJTYPE3).  Concatenation  Is 
achieved  by  correctly  ordering  the  output  operations.  When  we  say  that  proce¬ 
dure  dpJTYPEI  produces  text,  we  mean  that  the  procedure  uses  the  function  PUT 
to  output  text  in  the  same  manner  that  dpjnner  does. 


In  practice,  some  of  the  text  strings  Inherent  to  a  node  are  null. 


If  the  IOL  type  denotes  an  IDL  class,  then  It  is  reasonable  to  expect  the 
procedure  that  the  class  to  simply  dispatch  processing  depending  on  the  kind  of 
node  It  receives.  For  example.  If  the  IOL  class  TYPEl  is  defined  as 
TYPEl  i-  inner  I  leaf  ; 


and  there  Is  a  discriminating  function.  KINO ,  that  operates  on  nodes  of  the 
class,  then  the  procedure  dp_TYPE1  can  be  written. 

procedure  dp_TYPEl( Node i  in  TREE)  is 
begin 

cnee  KXND(Node)  is 

when  inner  ->  dp_lnner( Node)} 
when  leaf  ->  dp_leaf ( Node ) j 

end  dpJTTPEl; 


The  procedure  to  handle  nodes  of  a  class  can  be  optimized  to  do  processing 
for  the  nodes  in  that  class  If  the  nodes  are  sufficiently  similar.  1.9. .  they  share 
similar  attributes  or  generate  the  same  text  strings.  For  example,  in  Diana  the 
class  10  contains  only  nodes  that  represent  Identifiers  and  all  Identifiers  are 
reconstructed  from  the  /x_symrep  attribute.  We  use  this  to  advantage  In  Pret- 
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tyPrlnt  by  processing  all  nodes  in  the  class  ID  with  a  single  procedure. 


For  nodes  without  descendants,  the  leaf  nodes,  a  procedure  similar  to  the 

procedure  for  inner  nodes  Is  used.  Although  there  are  no  structural  attributes. 

we  assume  a  lexical  attribute.  Ixjtaxt.  that  contains  text  associated  with  the  leaf. 

Again,  the  existence  of  an  accessing  function.  LX_TEXT  that  returns  the  value  of 

the  attribute  Is  assumed. 

procedure  dp_le&£( Mode :  in  TREE)  is 
begin 

PUT("TextO")i 
POT(  UC_TEJCr(  Node  )  )  ) 

PVT(  "Textl" )} 
end  dp_leof  j 


2.1.1.  Simple  Example 

We  now  apply  this  technique  to  the  reconstruction  of  Ada  from  Diana.  As  an 
example  consider  the  Diana  node  constant,  which  represents  the  declaration  of  a 
constant  object.  The  syntax  for  the  declaration  of  a  constant  object  In  Aoa 
follows. 


constant_object_declaration  i 

identifier_list  t  constant  subtype_ indication  : -  expression  j 
I  identifier_list  »  constant  cons t rained_array  _def ini t ion 
expression  > 


The  Diana  node,  constant,  represents  a  constant  object  declaration. 


constant  ->  aa_ld_s 

aa^ypajspac 

aa_j3blect_def 


i  tojs, 

t  TCTEJ3PEC, 
i  OBJECT_PEF» 


Using  the  package  Diana  described  In  Chapter  4  of  the  DRM,  which  provides 
the  operations  on  the  Diana  data  type,  we  write  the  following  procedure  to 
reconstruct  the  source  for  a  constant  declaration. 


procedure  dp_constant(Hodei  in  TREE)  is 

begin 

dp_ID_S( AS_ID_S( Mode ) ) i  —  print  identifier  list 

Put("t  constant  " )i 

dp_TWE_SPEC(AS_TYPE_SPEC(Hode))»  —  print  subtype 
dp_0BJ8CT_0EP( AS_OBJECT_DEP( Node ) ) >  —  print  ' t-’  expression 

Put("»")» 
end  dp.constanti 
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In  other  words,  reconstructing  the  text  for  a  constant  object  declaration 
requires  the  following  pieces  of  text  to  be  concatenated: 

•  the  Identlfier.llst;  the  text  for  the  Identifier  list  Is  created  by  a 
procedure  similar  to  dp_conatant.  one  that  operates  on  ld_s  nodes. 

•  a  colon  and  the  MM  keyword  ‘constant*  (note  this  Includes  a  space 
after  the  word  ‘constant*) . 

•  the  subtype_lndfcatlon;  the  text  Is  created  by  a  procedure  that 
processes  the  aa_fype_apec  child. 

•  the  expression;  the  procedure  processing  the  aa~oblect_def  child 
produces  the  text  for  the  *:  =*  as  well  as  the  expression,  and  finally 

•  a  semicolon  to  end  the  declaration. 


For  some  level  of  completeness  we  consider  the  procedures  to  reconstruct  the 
source  for  two  of  the  children  of  the  node  constant:  aajd_a.  the  Identifier  list; 
and  ea_ob/_def.  the  object  definition  expression. 


The  Identifier  list  Is  a  sequence  of  Identifiers. 
ID_3  i i»  id_s; 


id_s  «>  aajlat  t  seq  of  xoi 

Sequences  are  handled  using  the  Diana  operations  LIST.  HEAD,  and  TAIL.  LIST 
returns  a  value  of  type  SEQ_TYPE  that  is  a  sequence  of  IDL  nodes.  HEAD 
returns  the  first  node  In  the  sequence  and  TAIL  returns  the  sequence,  possibly 
empty,  that  remains  after  the  first  node  Is  removed.  IS_EMPTY  returns  a 
boolean  value  True  when  the  sequence  Is  empty.  (The  procedure  does  not 
begin  with  a  check  for  an  empty  sequence  as  the  Aoa  syntax  does  not  permit  an 
empty  list) . 


procedure  dp_ld_s<Nodet  in  TREE )  le 
Li  SEQ_TVPEi 

begin 

L  i«  LIST(tfode); 
dp_ID(  HEAD(  L) ; 

L  t-  TML(L)> 
while  not  IS_£MPTY(  L) 

loop 

POT 

dp_ID< HEAD< L)| 

L  i-  TAILCDj 
and  loop; 
end  dp_id_s ; 


—  ho ids  list  not  processed 


—  print  the  first  id 

—  process  the  remaining 


—  separate  Id’s  with  " 

—  print  next  Id 

—  process  the  remaining 


The  procedure  dp_ld_s  Iterates  over  the  sequence  of  nodes.  For  each  node 
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the  procedure  dp_ID  Is  called  to  process  the  leaf  nodes  that  are  the  Identifiers. 
Before  each  node  (except  the  first)  a  comma  is  Introduced,  thereby  separating 
each  identifier  in  the  list  with  commas. 

In  presenting  the  procedure  for  dp_ld_s  we  have  simplified  the  treatment  of 
identifier  lists.  In  actuality  the  process  Is  complicated  by  the  fact  the  Identifiers 
could  be  label_lds.  Sequences  of  label_!ds  should  not  be  separated  by  commas 
(see  Section  2.2.1  on  page  33). 

The  object  definition  Is  represented  by  a  node  In  the  class  OBJ_P£F.  The 

nodes  In  this  class  are  the  nodes  of  the  class  EXP  and  the  node  void.  Void 

Indicates  that  no  object  definition  appears  In  the  declaration.  Although  the 
object  definition  for  a  constant  declaration  may  never  be  void,  the  node  constant 
!3  also  used  to  represent  deferred  constants.  Deferred  constant  declarations 
'  '  have  no  object  definition  expression  and  Diana  represents  this  with  a  void  node 
as  the  as~.obl_.def  child.  The  procedure  to  reconstruct  the  text  must  account  for 
this  fact.  In  particular.  It  must  assure  that  the  *:=*  is  not  generated  when  the 
object  declaration  is  absent. 

The  procedure  to  process  the  class  OBJ_DEF  Is  an  example  of  processing  for 
an  IDL  class.  The  function  KIND  is  used  to  discriminate  between  nodes  within 
the  class. 

procedure  dp_OBJ_DEF( Node :  in  TREE)  is 
case  KIND(Node)  of 

dn_void  ■>  null;  —  no  object  definition 

others  ■>  Put( —  all  object  defs  begin  with  ” : »“ 
dp_EXP( Node ) ; 

end  case; 

end  dp_OBJ_'EF; 

2. 2.  Anomalies 

The  procedures  needed  to  describe  the  remaining  Diana  nodes  are  generally 
straightforward.  The  steps  required  to  reconstruct  most  nodes  can  be  deduced 
from  Chapter  2  of  the  ORM.  However,  there  are  some  Diana  nodes  for  which 
obvious  solutions  do  not  exist.  In  this  section  we  discuss  the  implication  of 
these  nodes  and  describe  the  processing  necessary  In  order  to  reconstruct  the 
source  for  these  nodes. 

That  we  must  treat  certain  nodes  delicately  to  recreate  the  source  does  not 
Imply  that  Diana  In  some  way  destroys  the  original  source.  On  the  contrary,  the 
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source  is  reconstructable.  We  are  merely  pointing  out  the  reconstructions  that 
may  not  be  obvious  to  the  casual  observer. 

2.2.1.  Label  Identifiers 

The  defining  occurrence  of  a  label  Identifier  Is  represented  by  the  Diana  node 
label_ld.  The  defining  occurrence  of  a  loop_name  or  btock_name  is  also 
represented  by  labe(_id.  Not  only  Is  there  a  semantic  difference  between  the 
two.  there  is  a  textual  difference  in  how  the  identifiers  are  represented.  The 
label  identifier  should  be  enclosed  in  double  brackets  (*«  »*)  while  the 

block_name  should  appear  without  the  brackets.  To  solve  this  requires  upmerg- 
Ing  the  processing  of  the  labe!_ld  into  the  nodes  that  can  be  its  parent.  As 
there  are  only  two  such  nodes,  there  is  no  great  difficulty  In  doing  this. 

The  node  named_stm  is  used  to  represent  named  blocks  and  named  loops. 
The  aa_td  son  of  this  node  will  be  a  labef_id  representing  the  name  of  the  block 
or  loop.  In  this  situation  the  processing  of  labei_ld  Is  no  different  that  any 
other  Identifier. 

The  node  (d_s  represents  an  Identifier  list.  It  is  also  used  to  represent  the 
sequence  of  label  Identifiers  preceding  a  statement.  In  the  majority  of  contexts 
the  source  Is  the  concatenation  of  all  the  Identifiers  in  the  sequence,  separated 
by  commas.  However,  when  id_s  represents  a  sequence  of  label  Identifiers,  the 
source  Is  the  concatenation  of  the  Identifiers  without  commas  and  with  each 
Identifier  bracketed. 

Since  brackets  around  the  labels  occur  only  in  the  context  of  an  Identifier 
list.  It  Is  logical  to  place  decision  logic  for  handling  labels  into  the  routine 
processing  the  Identifier  list.  The  solution  requires  that  ihe  routine  reconstruct¬ 
ing  the  Identifier  list  know  which  type  of  identifier  appears  in  the  list.  The  type 
of  an  Identifier  can  be  determined  by  using  the  Diana  function  KIND.  Figure 
2-1  on  page  34  presents  the  two  procedures  needed  to  recreate  the  text  for  the 
node  !d_s.  The  first  procedure  recreates  the  text  for  all  identifiers,  both  used 
and  defining  occurrences,  and  the  second  handles  the  sequence  itself. 

Procedure  dpjdjs  begins  by  printing  the  first  identifier  In  the  sequence. 
Because  correct  Diana  Is  assumed,  there  Is  no  test  for  an  empty  Identifier  list. 
The  procedure  dp_IO  is  called  to  print  the  identifier.  If  the  type  of  identifier  Is 
label_id  then  the  identifier  is  bracketed.  After  producing  the  first  identifier. 
dp_ld_a  enters  a  loop  to  process  the  remaining  identifiers.  A  comma  is  Inserted 
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—  procedure  for  all  nodes  in  class  ID 
procedure  dp_ID< Node i  in  TREE)  is 

—  Mode  should  be  in  the  IDL  class  ID 

—  All  identifiers  treated  the  sane, 

—  lx_sy*rep  contains  the  representation 

begin 

Put<  UC_SYMREP(  Node  )  )  ; 
end  ID; 


procedure  dp _Label_id( Node t  in  TREE)  is 

begin 

Put( “<<");  —  label  ids  bracketed  by  "<<  >>* 

dp.nXNode); 

Put(  ">>"); 
end  dp_Label_id; 


—  procedure  for  node  14_e 
procedure  dp_Id_s( Node i  in  TREE)  is 

—  Node  is  an  id_s  node 

Seqi  SEQ_TYPE j  —  local  variable  to  hold  the  sequence 

begin 

Seq  i»  LIST(NOde);  —  get  the  list  of  id  nodes 

if  KIND(  HEAD(  Seq ) )  -  dn_label_id  then 
dp_labelwid( HEAD( Seq ) ); 

dp_ID(HEAD<  Seq)); 
end  if; 

Seq  s-  TAIL(  Node ) ; 
stiile  not  I3JEHPTT(3eq) 
loop 

if  KIND< HEAT*  Seq ) )  -  dn_label_id  then 
dp_lnbel_id( HEAD< Seq ) ); 

else 

Put(",")»  —  regular  ids  separated  by 

dp_ID< HEAD< Seq) )> 
end  if; 

Seq  i-  TAII<(  Node ) > 
end  loop; 
end  dp_ld_s; 


Figure  2-1:  Procedures  To  Reconstruct  td_s  Node 
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before  each  of  the  remaining  Identifiers  If  the  identifiers  are  not  labels.  If  the 
Identifier  Is  a  label  no  comma  Is  Inserted  and  the  Identifier  Is  bracketed. 

2.2.2.  Task  Types 

An  Ada  task  type  specification  Is  represented  in  Diana  by  a  type  node  whose 
asjtype_jspec  child  Is  a  task_spec  node.  The  node  task_spec  Is  the  only  node 
In  the  class  TYP€,J}P€C  requiring  text  to  be  generated  before  the  Ada  reserved 
word  ‘type*.  The  text  generated  lor  a  task  type  declaration  Includes  the  reserved 
word  ‘task*. 

task  type  <typenam>  is  <taak_»pecification>; 

Every  other  type  declaration  begins  with  'type*, 
type  <typenaae>  is  <type_apeci£ic&tion>> 

This  problem  requires  that  the  procedure  reconstructing  the  source  for  a  type 
node  must  inspect  the  aajtype^jspec .  The  procedure  dp_Jype  Is  shown  In  Figure 
2-2. 


procedure  dp_Type(  Node  *  in  TREE)  is 
begin 

if  KINDf  AS_TWE_SPBC(  Node ) )  -  dn_task_spec  then 
Put( "task  ")» 
and  if; 

Put( "type")) 

dp_ID( AS_ID( Node ) ) i  —  task  identifier 

dp_var«( A3_VAR_S( Node ) ) j  —  discriminants 

Put( "  is  ")i 

dp_T»E_SPEC(  AS_T»E_SPEC(  Node  ) ) ; 

PUt(-|")) 
end  dpjpype) 


Figure  2-2:  Procedure  To  Recreate  Type  Declarations 


2.  2.  3.  Subprogram  Declarations 

Aoa  subprogram  declarations  are  represented  by  the  node  subprogram_decl. 
This  node  has  three  attributes.  The  first,  as  ^designator  is  the  subprogram 
Identifier.  The  second,  asjteader  is  the  subprogram  header.  The  third  Is  used 
for  renaming  and  generics,  the  aa_pubprogram_def  attribute. 
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The  second  attribute  references  a  node  in  the  IDL  class  HEADER.  The  nodes 
function  and  procedure  belong  to  this  class.  Both  nodes  have  an  attribute. 
aa_param_a  which  references  the  format  part  of  the  subprogram  declaration.  In 
addition,  function  has  a  aa_pamo_vold  attribute  which  references  the  return  type 
of  the  function. 

The  nature  of  the  subprogram_decl  and  HEADER  nodes  make  it  difficult  to 
reconstruct  the  source  In  one  pass.  Consider  the  reconstruction  of  the  following 
subprogram  declaration. 

procedure  ProclD  (par ami!  In  TREE); 

The  declaration  Is  represented  by  a  subprog  ram_d#cl  node.  Knowledge  of  the 
aajiaadar  child  of  this  node  Is  needed  to  determine  that  the  subprogram  Is  a 
procedure.  Then  the  aajd  child  is  needed  to  recreote  the  subprogram  iden¬ 
tifier.  Following  the  identifier,  the  aa_header  child  Is  needed  again  to  recreate 
the  formal  part  of  the  declaration. 

There  are  several  methods  for  solving  this  problem.  One  is  to  use  KIND  to 
determine  the  type  of  the  aa_header  child.  Another  method  requires  the  routine 
reconstructing  the  declaration  to  pass  the  identifier  to  the  routine  processing  the 
header.  We  illustrate  the  latter  technique.  Figure  2-3  on  page  37  presents  the 
procedures  needed  to  reconstruct  a  subprogram  declaration.  Procedure 
dpJSubprogram_d«cl  processes  the  node  subprogram_decl .  procedure  dpJiEAOER 
dispatches  processing  for  nodes  In  the  class  HEADER,  and  dp_proc»duro 
processes  the  node  procedure. 

Note  that  this  treatment  applies  to  subprogram  bodies  as  well.  The  routine 
reconstructing  the  text  for  the  subprogram  body  must  pass  the  identifier  to  the 
procedure  processing  the  aa_beader  attribute. 

2.2.4.  Blocks 

The  node  block  Is  used  In  three  different  Aoa  contexts.  It  represents  a  block 
statement.  It  also  represents  the  block  of  a  named  statement.  Lastly,  block 
represents  the  body  of  a  subprogram,  task,  or  package. 

The  block  node  has  three  structural  attributes. 

block  ->  aa_/fem_a  t  ITEM_S(  —  declaration* 

aa_afm _a  i  STH_s,  —  statement* 

aa_altar  natives  j  alternative_s  j  —  exception* 


The  most  straightforward  block  Is  a  simple  block  statement. 


The  text 
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—  process  the  node  aubprogram_dec 1 

procedure  dp_aubprogra»_decl( Node >  In  TREE)  is 

begin 

—  pess  the  header  and  id  to  the  routine  for  the  header 

—  tX_SYMR£P  returns  the  text  for  the  identifier 
dp_HEADER(  AS_HEADER(  Node  ) ,  LK_SYMREP(  AS_DESIO«ATOR(  Node  >  )  )> 

—  process  the  siibprogram_daf  child 
dp_SUBPHOGRAH_DEF(  AJ3_SUBPROGRAH_DEF(  Node  )  ) ; 

Put (-;"); 

end  dp_subprogram_dec 1 > 


—  process  nodes  in  the  class  HEADER;  it  receives  as  input  the 

—  node  and  the  text  for  the  identifier 

procedure  dp_HEADER( Node >  in  TREE;  Identi  in  String)  is 
begin 

case  1CIND<  Node )  is 

ehan  dn_ function  ->  dp_function( Node, Xdent ) > 

Vhen  dnjprocedure  «>  dp_procedure( Node , Xdent ) j 
when  dn_entry  ■»  dp_entry( Node, Xdent )/ 

end  case; 

end  dp_HEADER; 


—  process  the  node  procedure;  receives  the  node  and  the  identifier 

procedure  dp_procedure( Node t  in  TREE;  Identi  in  string)  is 
begin 

Put( "procedure  "); 

Put(Ident); 

dp_paraa_s(  AS_PARAH_S(  Node ) ) ;  —  formal  part 

end  dp_pxocedure; 


Figure  2-3:  Procedures  To  Recreate  A  Subprogram  Declaration 
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generated  by  this  node  follows. 

declare 

<as_iten_s> 

begin 

<a*_stm_s> 


<a»_altemative_8> 

end; 


Note  that  ‘declare*  is  only  recreated  when  aajtam_a  is  not  empty  and 
'exception*  Is  only  recreated  when  aa_alternatlva_a  Is  not  empty. 

The  situation  is  complicated  slightly  when  the  block  statement  is  named2. 

The  named  block  Is  represented  by  the  node  named_stm  with  a  child,  aa_atm. 

that  Is  a  block  node.  In  this  case  the  text  for  the  block  differs  by  the  identifier 

after  the  block  end. 

<  identifier  > : 

<aa_itemL_s> 

begin 

<as_stm_s) 

exception 

<ax_altemative_s> 
end  < identifier); 


In  the  final  Instance,  block  Is  used  to  represent  the  body  of  a  subprogram, 

package,  or  task.  In  this  case  the  text  associated  with  the  block  does  not 

Include  the  Ada  reserved  word  ‘declare*  and  the  identifier  following  the  'end*  is 

optional  (we  have  consistently  chosen  to  Include  It) . 

< subprogram,  package,  or  tank  specification) 

<as_itesL.s> 

begin 

<as_stn_8> 

<as_altemative_8> 
end  <identifier>; 


We  consider  the  processing  for  these  three  cases  to  be  sufficiently  different 
to  warrant  treatment  by  three  separate  procedures. 

—  this  handles  block  statements;  it  is  passed  the  node  block 
procedure  dp Jalock( Node >  in  TREE); 

—  this  handles  the  named  blocks;  it  is  passed  block  and  an 

—  the  identifier  that  should  follow  the  end 


2A  Mm  Her  problem  exist*  with  named  loops.  The  solution  is  analogous  to  the  solution  used  tor  named 
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procedure  dp j9lodc( Node t  in  TREE;  Idenfct  in  String)* 

—  this  handles  the  subprogram,  package,  and  task  bodies. 

procedure  dp_block_stub<Nodei  in  trke); 

The  first  two  procedures  are  overloaded  with  the  name  dp_t>lock.  The  first 
procedure  has  as  its  argument  the  block  node.  This  creates  the  text  for  a  block 
statement.  It  Is  typically  called  by  the  routine  that  processes  the  STM  class. 

The  second  procedure  receives  two  arguments:  the  block  node  and  the 
Identifier  that  names  the  statement.  This  procedure  Is  called  only  from  the 
routine  that  processes  the  node  named.stm.  It  will  generate  the  text  for  the 
block  and  place  the  identifier  after  the  reserved  word  'end'. 

The  last  procedure  actually  handles  the  class  BLOCKJSTUB.  There  are  only 
two  nodes  In  the  class:  block  and  stub.  When  the  node  Is  stub  the  procedure 
will  generate  the  text  ‘Is  separate'.  When  the  node  Is  block  It  will  generate  the 
text  for  the  block  without  generating  the  reserved  word  'declare'. 

The  bodies  of  the  three  procedures  are  shown  In  Figure  2-4  on  page  40. 

2. 3.  Comments 

PREmPniNT  uses  the  simplest  of  commenting  strategies.  The  algorithm  used 
prints  the  comment  associated  with  a  node  after  the  text  for  the  node  has  been 
reconstructed.  When  creating  comments  In  an  unformatted  text  string  the  only 
constraints  are  that  the  comment  be  preceded  by  ’ — *  and  followed  by  an  end  of 
line.  If  the  comment  extends  over  one  line,  each  additional  line  must  begin  with 
* — *.  This  issue  is  addressed  In  Section  3.2.4  on  page  52  along  with  a 
discussion  of  other  constraints  for  producing  comments  in  formatted  source  text. 

All  Diana  nodes  related  to  the  Ada  source  have  the  attribute  lx_commonta. 
This  attribute  records  a  comment.  The  type  of  the  attribute  Is  the  IDL  private 
type  ‘comments*.  We  assume  this  type  Is  Implemented  such  that  the  function 
Void  will  return  the  boolean  True  if  the  comment  is  empty.  The  treatment  of 
comments  for  ail  nodes  Is  the  same.  We  create  a  single  procedure  to  process 
all  comments. 
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procedure  dp_i>lock( Node :  in  TREE)  ia 

tngll) 

if  not  I3_EHPTY( LIST(  A3_ITE>t_S(  Node ) ) )  then 
Put( "declare" ); 
dp_It«n_»{ AS_ITEMS_S( Node ) ) ; 
end  if; 

Put( "begin"); 
dp_stn_s(  AS_3T»(_S  )  ; 

if  not  IS_EMPTY( LIST( AS _ALTERNATIVE_S( Node ) ) )  then 
Put( "exception" ) ; 

dp_Alternat ive_s(  AS _ALTERNAT  IVE_  S  ( Node  ) ) ; 
end  if; 

Put(."end; "  ); 
end  dpjblock; 


procedure  dp  Jblock( Node t  in  TREE;  I dent:  in  String)  is 

begin 

if  not  IS J£HPTY(  LIST(  AS_ITEM_S(  Node ) ) )  then 
Put< "declare" ); 
dp_Iteis_s<  A3_rTEK3_S{  Node ) ) ; 
end  if; 

Put( "begin"); 
dp_stei_e(  AS_STH_S  ) ; 

if  not  IS_EMPTY(  LIST(  AS _JVI/TERNATIVE_S(  Node ) ) )  then 
Put( "exception" ); 

dp_Alternative_s(  AS _jU7TERNATrVE_S( Node ) ) ; 
end  if; 

Put("end");  —  named  block:  identifier  follows  end 

Put(Ident); 

Put(";"); 
end  dp Jb lock; 


procedure  dp_block_stub( Node «  in  TREE)  is 
begin 

if  KIND( Node )  -  dn_stub  then 
put  ("is  separate"); 

else 


—  "declare"  not  printed 

dp_X  tem_*(  AS_ITEMS_3(  Node ) ) ; 

Put( "begin"); 
dp_Stn_s(  AS  J5TH_S  )  ; 

if  not  IS JSMPTY( LIST(  AS _ALTERNAT IVE_S ( Node ) ) )  then 
Put( "exception" ); 

dp_Altemative_8(  AS_ ALTERNAT  rVE_  S  (  Node  )  ) ; 
end  if; 

Put( "end;"); 
end  if; 
end  dp  Jb  lock; 


Figure  2-4:  Procedures  for  Reconstructing  Blocks 


Source  Reconstruction 
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procedure  dp_coenenba( Node t  in  TREE)  la 
begin 

if  not  Void(  LX_CcmzNTS(  Node ) )  then 
Put< " — ")» 

Put(  l*_COMMENTS<  Node )  ); 

Put(cr  &  If),  —  end  of  line  terminators 

end  if; 

end  dp_coonents> 


To  Include  comments  In  the  source  reconstructed  from  a  constant  node,  the 
example  from  Section  2.1.1  on  page  30.  we  simply  add  a  statement  to  call 
dpjComments  at  the  end  of  the  procedure, 
procedure  dp_constant( Nodes  in  TREE)  is 


begin 

dp_ID_S(  AS_ID_S(  Node ) ) ; 

Put( " :  constant  ")> 
dp_T»E_SPEC(  JtS_TYPE_SPEC(  Node  )  ) ; 
dp_OBJECT_DEF( A3_0BJECT _DEK( Node ) ) I 
Put( "  ); 

dp_caanents( Node ) ;  —  print  comment  if  present 

end  dp_constant; 


The  source  reconstruction  algorithm  appends  the  comment  to  the  text  tor  the 
node  it  Is  attached  to.  Thus,  the  effect  on  the  reconstruction  of  a  constant 
ob|ect  declaration  varies.  Consider  the  Ada  statement 

ID1,  ID2 1  constant  subtype  EXP;  —  comment  text 

If  the  comment  text  Is  attached  to  the  ld_s  node  the  statement  Is  reconstructed 
as 

lot ,  tost  —  comment  text 

t  constant  SUBTYPE  »■  EXP; 

If  the  comment  Is  attached  to  the  OBJ_TYPE_SPEC  the  statement  Is  reconstructed 

as 

ID1,  ID2 :  constant  subtype  —  comment  text 

»•  EXP; 


Of  course,  a  responsible  pretty-printer  will  Indent  the  continuation  of  the 
statement  on  the  next  line.  In  this  chapter  we  have  only  presented  the  design 
for  a  pretty-printer  to  produce  unformatted  text.  Formatting  Issues  are  discussed 
In  Chapter  3. 
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CHAPTER  3 
FORMATTING 


In  this  chapter  we  discuss  the  formatting  of  source  text  and  the  formatting  of 
Ada  source  text  In  particular.  PrettyPrint  formats  reconstructed  source  text  by 
calling  entries  In  FORMAT,  an  Aoa  package  which  provides  an  Interface  to  the 
output  medium,  assistance  In  placement  of  line  breaks,  and  support  for  Inden¬ 
tation. 

This  chapter  begins  with  a  discussion  of  the  classical  formatting  problems, 
followed  by  a  general  discussion  of  our  design  for  solving  the  set  of  classical 
problems.  The  chapter  closes  with  the  presentation  of  the  package  FORMAT. 

3. 1 .  Classical  Formatting  Problems 

A  proper  understanding  of  the  problems  associated  with  pretty-printing  re¬ 
quires  an  appreciation  of  the  goal  of  a  pretty-printer.  In  a  word,  the  goal  of 
every  pretty-printer  is  to  produce  * readable *  source.  Readability  is  that  quality 
that  makes  a  program  easy  to  understand,  debug,  modify,  test,  and  maintain. 
Insofar  as  programming  is  an  art.  what  makes  a  program  readable  is  a  question 
of  aesthetics  and  is  often  debated.  Indeed,  some  aspects  of  pretty-printing  that 
we  present  as  facts  are  actually  our  own  opinions. 

There  are  some  generally  accepted  tenets  of  pretty-printing:  the  formatting  of 
the  source  should  help  the  reader  visualize  the  syntax;  the  nesting  of  the 
program  should  apparent  at  a  glance:  and  Individual  statements,  declarations, 
and  expressions  should  be  discernible. 

Consistency  is  another  benefit  accrued  by  pretty-printing.  Programs  formatted 
by  the  same  pretty-printer  are  consistently  arranged.  A  pride  of  programmers 
that  are  sharing  code  can  use  the  output  of  a  pretty-printer  as  the  de  facto 
standard  of  readability.  The  pretty-printed  programs  thus  share  a  homogeneous 
style  and  another  programmer's  code  does  not  look  foreign. 

The  Aoa  LRM  uses  an  Implicit  formatting  style  for  Its  programming  examples. 
The  pretty-printer  we  have  designed  formats  in  this  style.  The  examples 
presented  in  this  section  also  are  formatted  In  this  style. 
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3.1.1.  Indentation 

Indentation  Is  the  single  most  Important  aspect  of  program  formatting.  .  Proper 
Indentation  can  be  used  to  indicate  program  nesting,  and  to  diagram  control 
constructs.  In  the  idyllic  situation  where  all  programs  are  terse  and  compact 
enough  that  each  statement  can  exist  on  its  own  line  Indentation  is  easy.  One 
example  of  the  use  of  Indentation  for  Aoa  Is  to  show  nested  scopes, 
procedure  Nest  is 

Nunber  t  constant  i-  42 j  —  declarations  indented 

Object  I  INTEGER) 

begin 

Object  i*  Number;  —  statements  indented 

end  Nest; 

The  declarations  and  statements  within  the  procedure  body  are  distinguishable 
from  the  syntax  defining  the  body  by  their  Indentation.  The  'begin*  and  'end' 
are  not  Indented  and  clearly  demarcate  the  bounds  of  the  body. 


Similarly.  Indentation  can  make  the  conditional  clauses  of  an  Aoa  'If*  state¬ 
ment  more  visible, 
procedure  Nest  is 

Nuaber  t  constant  j-  42;  —  declarations  indented 

Object  i  INTEGER; 

begin 

Object  i-  Number;  —  statements  indented 

If  Object  -  Number  then 

Object  i-  Nuaber;  —  each  conditional  clause  indented 

else 

Object  i-  Number; 
end  if; 
end  Nest; 


The  effect  of  the  Indentation  Is  additive.  Each  construct  that  uses  indentation 
Indents  In  from  the  current  level.  The  Increasing  indentation  Is  the  first  problem 
a  pretty-printer  has  to  solve.  The  number  ot  spaces  tor  each  Increment  of 
Indentation  must  be  small  enough  that  at  the  maximum  excursion  the  space 
remaining  on  the  line  is  usable.  The  obvious  solution  Is  to  base  the  Indentation 
Increment  on  the  maximum  indentation  depth.  Ot  course,  the  quantum  nature  of 
the  output  medium  (f.e.,  the  minimum  Indentation  Is  at  least  one  space)  may 
force  the  maximum  excursion  to  exceed  a  reasonable  bound  for  even  the  smallest 
Increment,  indentation  beyond  this  point  should  be  prevented. 


It  should  be  noted  that  a  program  with  control  structure  nesting  so  deep  that 
further  Indentation  Is  prevented  Is  probably  too  complex  to  be  readable  anyway. 
The  program  should  be  analyzed  to  see  where  complexity  can  be  removed,  most 
likely  by  dividing  It  Into  less  complex  modules,  thereby  making  each  module  more 
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readable  and  the  whole  more  understandable. 


3.1.2.  Line  Breaks 

The  programs  that  a  pretty-printer  has  to  format  are  not  Ideal.  Simply 
choosing  to  indent  based  on  control  structures  will  not  gain  readability  by  itself  if 
statements  extend  beyond  the  length  of  the  line.  Consider  the  formatting  of  an 
If  statement. 

If  condition  than 

objsctl  i-  expression!  +  expression  > 
procedure_call; 

elan 

abject 2  expression!  +  expression j 

end  if) 

As  long  as  the  line  width  Is  large  enough,  this  formatting  Is  very  readable.  The 

situation  Is  less  sanguine  when  fewer  columns  are  available.  The  following 

example  is  unreadable  because  the  Indentation  Is  lost  when  the  statement  is 

continued  on  the  next  line. 

If  condition  then 

objectl  !-  expressionl  + 
expression  ; 
procedure_call ; 

else 

objects  !-  expressionl  + 
expression; 
end  if; 

Using  the  current  level  of  indentation  for  the  continuation  of  the  statements 
Increases  the  readability  but  still  leaves  room  for  Improvement. 

if  condition  than 

objectl  expressionl  + 
expression; 
procedure_call ; 

else 

objects  i-  expressionl  + 
expression; 
end  if; 

At  first  glance,  the  continuation  of  the  broken  line,  the  text  *expresaion2‘.  looks 

like  a  separate  statement.  it  has  the  same  visual  importance  as  the  call  to 

procedure  ‘procedure _call*.  Indenting  the  continuation  of  lines  will  avoid  this 

confusion.  The  following  Is  much  more  readable. 

if  condition  then 

objectl  ;»  expressionl  + 
expression  > 
proceduxe_call; 

else 

objects  i"  expressionl  + 
expression ; 
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end  If; 

Choosing  where  to  break  a  line  can  be  as  Important  as  choosing  which 
column  to  start  the  continuation  of  a  broken  line.  Consider  the  following 
statement. 

object 1  i-  expressionl  +  expression  +  £unction_call(  par ami , param2 ) ; 

On  a  shorter  line  this  statement  would  have  to  be  broken  and  continued  on  the 
next  line.  A  truly  awful  break  would  be  within  the  function  call. 

object 1  expressionl  +  expression  +  function_call( par ami, 

param2); 

An  Improvement  can  be  made  by  not  breaking  up  syntactic  elements.  The 
function  call  Is  an  expression  that  should  not  be  broken  up  unless  absolutely 
necessary.  Further  Improvement  can  be  made  by  moving  the  operator  to  the 
next  line.  This  move  makes  It  obvious  that  the  continuation  Is  indeed  part  of  the 
expression  on  the  previous  line. 

object 1  expressionl  +  expression 
+  function_call(  paraml,  param2); 

A  final  improvement  can  be  made  by  Indenting  the  continuation  of  the  broken 
statement  to  Illustrate  some  of  the  semantics.  In  this  case  the  function  call  Is 
part  of  the  expression  on  the  right  hand  side  of  the  assignment  statement. 
Beginning  the  continuation  so  It  Ilne3  up  to  the  right  of  the  assignment  operator 
can  help  to  show  this  relationship  and  aid  in  the  reader's  understanding. 

object 1  i«  expressionl  +  expression 

+  £unctior\_call(  paraml,  param2); 

Choosing  not  to  break  a  line  can  be  as  important  as  choosing  where  to  break 
a  line.  For  example,  an  If  statement  that  will  fit  on  one  line  should  most  likely 
be  placed  on  one  line.  The  terseness  of 

if  condition  then  statement;  end  if; 
recommends  It  above  the  sprawling 

if  condition  then 
statement; 

end  if; 

It  Is  also  advantageous  to  include  more  that  one  statement  on  a  line  when 
the  statements  are  brief. 

x  ««■  y;  z  x; 


The  statements  above  are  sufficiently  terse  to  be  Included  on  the  same  line 
without  loss  of  readability. 


Formatting 


Section  3.1.3  /  Page  47 


3.1.3.  Lists  and  Sequences 

Certain  Ada  syntactic  constructs  are  lists  of  Items.  When  breaking  a  con¬ 
struct  over  several  lines  lists  should  receive  special  consideration.  If  a  list  must 
be  broken  up  to  fit  on  a  line,  then  placing  each  Item  in  the  list  on  a  separate 
line  is  often  the  most  readable.  A  procedure  specification  is  the  most  Illustrative 
example  of  this  situation. 

procedure  Proc(Xi  In  Tl;  Ys  in  T2 j  Zi  in  T3); 

Suppose  only  the  first  two  parameter  specifications  fit  on  the  line.  Simply 

breaking  the  line  so  that  parameter  specifications  are  unbroken  is  reasonable. 

The  continuation  should  be  Indented  to  show  It  Is  part  of  the  list  of  actuals. 

procedure  Proc( X:  in  Tl;  Yt  in  T2 j 
Zi  in  T3 ) j 

One  possible  Improvement  is  to  treat  each  parameter  specification  with  equal 

Importance.  Thus,  if  one  parameter  specification  has  to  appear  on  a  separate 

line,  all  specifications  should  be  on  separate  lines.  The  example  is  reformatted 

to  show  this. 

procedure  Proc(Xi  in  Tl; 

Ys  in  T2; 

Zs  in  T3 ); 

In  declaring  the  last  example  superior  to  the  one  Immediately  preceding  it  we 
are  treading  lightly.  Like  any  aesthetic  pronouncement  it  has  a  subjective  basis. 
Nonetheless,  this  formatting  style  Is  used  throughout  the  PrettyPrint  design1. 

3.1.4.  Comments 

The  consideration  of  comments  during  text  formatting  is  a  poorly  understood 
issue.  In  many  cases  the  Introduction  of  comments  into  the  source  text, 
especially  comments  which,  like  Ada.  are  terminated  by  a  line  break,  will  force 
formatting  decisions.  For  example,  an  if  statement  that  can  be  placed  on  one 
line. 

if  condition  then  statement;  end  if; 

may  be  forced  by  comments  to  exist  on  three  lines. 

if  condition  then  —  the  condition  checks  Poo 

statement;  —  the  statement  sets  Poo 

end  if;  —  Poo  now  usable 


’it  doesn’t  weaken  our  esse  to  add  that  this  Is  the  way  tong  procedure  specifications  are  formatted  In 
the  AOft  LRM. 
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One  of  the  biggest  issues  Is  how  to  decide  where  comments  should  be  broken 

If  there  Is  Insufficient  room  on  a  line.  Unlike  Aoa  source,  where  the  syntax  Is 

defined,  there  Is  no  way  to  determine  the  context  of  the  comment.  One  such 
dilemma  exists  when  considering  the  formatting  of  a  statement  with  a  comment 
when  the  statement  does  not  fit  on  the  line.  Consider  the  following  statement. 

object  i-  expressionl  +  expression  +  func(x,y)»  —  expression  is  real 

If  the  statement  is  printed  on  a  line  that  Is  narrower,  then  the  question  of  how 
to  break  the  line  Is  unsolvable.  it  may  be  possible  to  break  the  comment  over 
several  lines. 

object  «•  expression  +  expression  +  func(x.y);  —  expression 

—  is  real 

The  comment  may  be  more  readable  as  a  complete  line  and  it  may  be  possible 

to  fit  the  statement  on  one  line,  and  the  comment  on  the  next. 

object  s-  expression  +  expression  +  func(x,y)> 

—  expression  is  real 

It  can  be  argued  that  the  statement  should  be  broken,  even  If  it  fits,  so  the 
comment  has  some  of  the  proper  context. 

object  expression  +  expression 

+  func(x,y)»  —  expression  is  real 

Of  course.  In  our  example  the  context  Is  lost  because  the  comment  refers  to 
expresslon2. 

An  omniscient  pretty-printer  would  recognize  when  a  comment  Is  best 
represented  by  breaking  the  statement  it  describes. 

object  expressionl  +  expression  —  expression  is  real 
+  £unc(x,y)> 

The  problems  related  to  comments  are  compounded  when  recreating  com¬ 
ments  from  an  Internal  representation  such  as  Diana.  In  this  case  the  comments 
are  In  some  manner  attached  to  the  nodes  of  a  parse  tree.  The  pretty-printer 
operating  from  this  tree  must  then  recreate  the  source  and  Intelligently  re-lnsert 
the  comments  Into  the  source.  To  be  effective,  the  comments  must  be  intel¬ 
ligently  associated  with  the  nodes  in  the  internal  representation,  and  the  pretty- 
printer  must  understand  this  association.  To  a  first  approximation  this  associa¬ 
tion  can  be  done  with  a  simple  strategy.  In  the  design  of  Pretty  Print  we  have 
assumed  that  a  comment  associated  with  a  node  should  be  printed  after  the  text 
for  the  node  is  printed.  However.  It  is  easy  to  Imagine  comments  that  may  be 
ruined  by  anything  less  than  an  omniscient  pretty-printer.  The  most  insidious, 
though  unlikely,  example  la  the  following  piece  of  Ada  text: 
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object  i«  express lonl  +  expressions 

I  I  I 

|  |  -  expression  is  column  number 

I  I 

|  -  expression  is  the  line  number 

I 

-  the  object  is  returned  to  caller 


3.1.5.  Whitespace 

One  way  to  make  a  program  more  readable  Is  to  make  its  components  easily 
distinguishable.  Towards  this  end  whitespace,  blank  lines  on  the  page,  can  be 
used  as  a  visual  separator.  Controlling  whitespace  Is  something  a  programmer 
can  do  better  than  a  pretty-printer  because  the  programmer  has  an  under¬ 
standing  of  the  logical  mapping  of  the  program  to  the  problem  the  programmer  is 
solving.  However,  because  Ada  provides  mechanisms  for  dividing  up  a  program 
(packages,  subprograms,  tasks,  etc.),  most  logical  divisions  will  also  be  syn¬ 
tactic  divisions.  PrettyPrint  does  add  whitespace  before  packages,  sub¬ 
programs.  and  tasks. 

3.1.6.  Page  Layout 

Equally  as  important  as  the  consideration  of  the  placement  of  source  text  on 
Individual  lines  Is  the  layout  of  the  lines  on  the  page.  It  Is  desirable  to  place 
single  ideas  on  a  single  page.  This  allows  the  reader  of  the  program  to  focus 
on  a  single  concept  at  a  time.  Just  as  It  is  undesirable  for  a  syntactic  element 
to  be  broken  over  a  line,  it  Is  undesirable  for  a  program  component  to  be 
broken  over  a  page.  Although  the  problem  Is  not  considered  In  the  design  of 
PRcriYPRiNT.  the  principles  used  In  formatting  statements  and  declarations  on 
Individual  lines  can  be  applied  to  the  layout  of  subprograms  and  packages  on  the 
page. 

3.  1 . 7.  Use  of  Fonts 

Using  fonts  to  distinguish  different  lexical  entities  can  be  an  effective  way  to 
Improve  the  readability  of  a  program.  In  this  document  we  have  consistently 
used  a  bold  typeface  when  writing  ADA  reserved  words.  The  reserved  words  are 
then  set  apart  from  the  identifiers  of  the  program,  and  the  syntactic  structure 
can  be  easily  recognized.  Another  possible  use  of  fonts  Is  an  italic  font  for 
comments.  A  pretty-printer  that  Is  reconstructing  the  source  text  can  use  fonts 
effectively  In  this  way. 
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Another  way  to  Improve  readability  la  to  use  consistent  representations  for 

Identifiers.  Ada  allows  several  representations  of  an  Identifier  to  be  used.  Case 
consistency  can  aid  In  recognizing  user  defined  Identifiers.  A  pretty-printer  can 
normalize  all  occurrences  of  Identifiers  so  that  all  representations  are  Identical. 

3. 2.  Solutions 

In  this  section  we  discuss  the  ways  PrettyPrint  solves  the  classical  formatting 
problems.  This  discussion  serves  as  an  introduction  to  the  operations  of 

FORMAT.  Section  3. 3  provides  a  more  complete  description  of  the  formatting 
operations  and  Chapter  4  contains  the  discussion  of  all  the  issues  related  to 
recreation  of  source. 

Before  considering  cases,  we  review  the  basic  operation  of  PrettyPrint. 

PrettyPrint  makes  two  passes  (tree  walks)  over  the  Diana  structure.  In  the  first 
pass  It  computes  the  number  of  characters  needed  to  print  each  node,  the 

largest  element  In  each  sequence,  and  the  maximum  nesting  depth  of  the 

program.  In  the  second  pass  the  source  Is  reconstructed  and  the  values 

computed  during  the  first  pass  are  used  to  make  decisions  concerning  line 
breaks  and  indentation. 

3.2.1.  Solving  Indentation 

Section  3.1.1  on  page  44  describes  the  classic  use  of  indentation  to 
represent  program  block  nesting,  and  syntax  structure.  PrettyPrint  uses  Inden¬ 
tation  In  the  classical  way.  Support  for  Indentation  is  provided  by  the  package 
FORMAT  through  the  two  entries  /ndenf  and  Undent.  Indent  causes  the  next  line 
to  be  Indented  by  an  Increment  from  the  previous  line.  Undent  reverts  the 
Indentation  to  that  In  force  before  the  current  Indentation.  The  complete 

functionality  of  these  procedures  Is  provided  In  Section  3.  3  on  page  54. 

The  increment  used  for  Indentation  Is  based  on  the  depth  of  control  structure 

nesting.  In  the  first  pass  over  the  D<ana  structure  the  maximum  nesting  level  for 

the  program  Is  computed.  This  value  Is  used  to  choose  the  Increment  for 
nesting.  The  Indentation  Increment  must  balance  the  need  for  distinguishable 
Indentation  against  the  need  for  usable  space  after  Indentation.  The  FORMAT 
function  Setlncrement  computes  the  indentation  Increment  based  on  the  nesting 
depth  of  the  program. 
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3.2.2.  Solving  Line  breaks 

The  procedure  NewLlne  can  force  the  Insertion  of  a  line  break  in  the 
recreated  source.  Forcing  a  line  break  can  be  used  to  shape  the  source  to 
show  the  syntactic  structure.  For  example.  NewLlne  is  called  after  the  keywords 
'then*,  'else',  'elseif.  and  'end  If*  when  displaying  an  if  statement.  NewLlne 
will  automatically  Indent  the  next  line  to  the  current  Indentation  level. 

PrettyPrint  also  needs  to  be  able  to  Intelligently  decide  where  to  break  long 
source  lines.  For  this  reason  the  number  of  characters  needed  to  print  the  text 
for  a  node  is  recorded  with  the  node.  For  example  consider  the  following 
statement. 

objactl  !—  expression:.  4-  expression  +  £unctior\_call(paraml,param2); 

Recorded  with  the  node  functlon_cal!  Is  the  number  of  characters  needed  to  print 
the  function  call.  Before  printing  the  function  call  the  number  of  characters 
required  can  be  compared  with  the  number  of  characters  remaining  on  the  line. 
Insufficient  space  can  be  detected  and  a  line  break  can  be  forced  before  the 
printing  of  the  function  call.  In  fact,  this  Inquiry  can  be  made  prior  to  the 
printing  of  the  '+*  operator. 

object  1  expression:.  +  express ion2 
4  £unction_call( paraml , param2 ) ; 

The  function  Remaining  returns  the  number  of  spaces  remaining  on  the 
current  line. 

FORMAT  provides  support  for  controlling  at  which  column  the  continuation  of  a 
line  begins.  The  function  Position  returns  the  current  position  on  the  line,  and 
the  procedure  Setlndant  will  set  the  current  Indentation  to  a  specific  column.  It 
Is  possible  in  the  example  above  to  force  the  continuation  of  the  assignment 
statement  to  be  to  the  right  of  the  assignment  operator.  After  printing  the 
assignment  operator  Position  can  be  called  to  return  the  current  position  and  this 
value  can  be  used  as  the  argument  to  Setlndant. 

objactl  i«  expzeaaionl  4  expression 

4  £unction_call(paranl,param2)> 

The  Indentation  caused  by  Setlndant  Is  canceled  with  a  call  to  Undent. 
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3.2.3.  Solving  Lists  and  Sequences 

The  support  provided  by  the  subprograms  Position  and  Sotlndont  aid  In  the 
processing  ot  lists  of  syntactic  elements.  For  example.  11  the  parameter 
specifications  of  a  subprogram  specification  will  not  fit  on  one  line,  the  Inden¬ 
tation  can  be  set  so  that  all  of  the  parameter  specifications  line  up  underneath 
the  first  one.  Again,  the  most  Illustrative  example  Is  the  procedure  specifica¬ 
tion. 

procedure  Proc( X:  in  Tl> 

Y:  in  T2 » 

Z:  in  T3  )j 

Recorded  with  the  nodes  representing  lists  of  Items  is  the  number  of  charac¬ 
ters  needed  to  print  the  entire  list,  and  the  size  of  the  largest  element  In  the 
list.  Using  the  former.  PrettyPrint  can  determine  If  a  list  will  fit  on  the  current 
line.  Using  the  latter,  it  can  choose  an  Indentation  such  that  all  elements  in 
the  list  can  appear  on  a  single  line.  8y  comparing  the  space  remaining  with 
the  size  of  the  largest  element  in  the  list,  the  following  situation  can  be 
detected. 

procedure  Proc(Xi  in  Tl; 

Y_ie_a_long_najne  i  in 
T2  > 

Zi  la  T3); 

The  Indentation  can  be  selected  so  that  the  largest  parameter  specification  will  fit 
on  one  line.  The  resulting  format  Is  clearer. 

procedure  Proc 

(Xi  in  Til 

Y_ie_a_long_naae i  in  T2| 

Zi  in  T3); 

3.2.4.  Solving  Comments 

There  is  little  support  for  comments  In  PrettyPrint.  One  of  the  Inherent 
problems  with  formatting  comments  from  an  Internal  representation  Is  a  lack  of 
understanding  of  how  comments  are  associated  with  the  nodes.  In  particular 
Oiana  does  not  specify  this  association.  For  this  design  we  have  assumed  that 
the  comment  attached  to  the  node  Is  the  comment  that  appeared  after  the  node 
In  the  original  source.  When  recreating  the  source,  any  comments  are  placed 
In  the  recreated  source  after  the  text  for  the  node  has  been  created. 


PrettyPrint  does  not  account  for  the  length  of  comments  In  determining 
whether  text  will  fit  on  the  line.  This  Is  a  conscious  decision  on  the  part  of  the 
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designers.  The  reason  for  this  decision  is  that  it  Is  impossible  to  distinguish 
between  the  following  cases. 

objectl  «-  express ionl  +  expression^ ;  —  first  example 

abjectl  »»  express ion 1  + 

expression  j  —  a  second  example  with  a  longer  comment 

abjectl  i-  expressionl  +  expression; 

—  The  third  example  has  a  comment  the  length  of  three  lines. 

—  The  entire  comment  is  associated  with  the  statement  above, 

—  although  the  content  may  indeed  refer  to  a  statement  below. 

Without  a  way  to  Interpret  the  meaning  of  a  comment,  which  Is  beyond  the 
scope  of  a  pretty-printer,  there  Is  no  way  to  Intelligently  associate  comments. 
Instead  of  basing  formatting  decisions  on  questionable  Input,  we  have  chosen  to 
Ignore  comments  while  making  formatting  decisions. 

3.2.5.  Solving  WhiteSpace  and  Page  Layout 

PrettyPrint  adds  whitespace  to  the  reconstructed  source  by  calling  NewUno 
multiple  times.  Whitespace  Is  produced  as  a  buffer  for  subprogram  and  package 
specifications  and  bodies.  It  Is  also  produced  between  every  compilation  unit. 

pRETTYPRiNr  does  not  address  the  question  of  page  layout.  The  solution  to 
the  problem  Is  not  very  difficult.  The  second  pass  over  the  Diana  structure  can 
be  used  to  produce  a  tree  attributed  with  the  number  of  lines  needed  to  print 
each  node.  Then  a  third  pass  can  pass  over  the  tree  creating  formatted  source 
while  determining  page  breaks.  The  types  of  decisions  necessary  are  analogous 
to  the  decisions  needed  for  line  breaks.  If  a  program  body  contains  more  lines 
than  remain  on  a  page,  a  page  break  can  be  Inserted  before  the  body  so  it 
remains  intact. 

3.2.0.  Solving  Use  of  Fonts 

FORMAT  provides  a  mechanism  to  differentiate  between  different  lexical  items 
In  Ada.  ReservedForm .  IdentForm.  and  ComForm  are  used  to  append  reserved 
words,  identifiers,  and  comments  respectively.  No  commitment  Is  made  as  to 
how  they  are  represented. 
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3.3.  Package  ‘FORMAT* 

The  formatting  operations  supplied  by  FORMAT  were  casually  Introduced  in  the 
previous  section.  In  this  section  we  describe  the  complete  functionality  of  the 
Ada  package  FORMAT.  Figure  3-1  shows  the  FORMAT  package  specification. 
The  package  body  Is  not  specified  In  this  document. 

The  package  FORMAT  provides  functional  support  In  two  Important  ways. 
Firstly.  FORMAT  handles  all  of  the  output  of  the  recreated  source,  and  secondly. 
FORMAT  provides  support  for  proper  indentation. 

The  output  of  source  is  handled  by  operations  that  append  text  to  the 
previously  generated  source  text.  The  package  hides  any  device  dependency 
(particularly  If  boldface  and  Italics  are  to  be  used).  If  buffering  of  output  Is 
required,  the  buffering  will  be  transparent  to  the  the  programs  that  call  the 
FORMAT  routines. 

The  principle  reason  that  buffering  of  output  may  be  desired  Is  for  creating 
special  print  effects.  When  text  Is  appended,  the  text  is  qualified  as  either  an 
Ada  reserved  word,  identifier,  comment,  or  other  lexeme.  FORMAT  can  use 
output  device  characteristics  such  as  boldface  type.  Italic  fonts,  and  underlining 
to  visually  distinguish  these  classes  of  text.  Depending  on  the  output  device, 
undv..  ilng  and  boldface  may  require  printing  two  output  lines  without  a  linefeed 
to  achieve  the  desired  effect.  In  such  an  Instance  buffering  the  line  before 
printing  Is  absolutely  necessary. 

Buffering  also  eases  some  formatting  problems.  Consider  the  problem  of 
printing  a  lexeme  larger  than  the  space  remaining  after  Indentation.  In  such  a 
case  the  l'  dentation  should  be  reduced  to  allow  enough  space  tor  the  lexeme  to 
be  printed  if  the  spacing  for  Indentation  Is  output  directly  to  an  output  device  It 
Is  Impossible  to  reclaim  that  space.  A  new  line  would  have  to  be  started  with 
less  indentation  to  accommodate  the  lexeme,  leaving  a  blank  line  in  the  output. 
However.  If  the  output  Is  buffered,  the  space  used  for  the  Indentation  can  be 
reclaimed  from  the  buffer. 

Whether  the  output  is  buffered  or  not  Is  transparent  to  the  subprograms 
traversing  the  Diana  tree  constructing  the  source.  The  reconstruction  routines 
are  only  concerned  with  the  current  output  line.  The  operations  provided  append 
text  to  the  current  line  and  query  FORMAT  regarding  the  status  of  the  line  (such 
as  the  number  of  characters  remaining,  or  the  current  position  on  the  line). 
The  traversal  routines  also  may  force  a  line  break  into  the  output  either  ex- 
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—  Package  that  provides  operations  to  format  reconstructed  Ada  source 
package  format  is 
Line Length  : 

constant  POSITIVE  i-  120;  —  length  of  the  output  line 

type  Column  is 

range  0. .LineLength;  —  position  on  the  line 

—  There  are  four  procedures  to  append  text  to  the  output  buffer 
procedure  AddText( Text »  in  String); 

procedure  ResFora  —  add  Ada  reserved  words 

(Text;  in  String); 

procedure  CoaForm  —  add  coonanta 

(Text;  in  String); 

procedure  identFora  —  add  program  identifiers 

(Text i  in  String);  ^ 

—  There  are  two  function  to  return  Vtatus  of  the  output  buffer 

function  Remaining  return  Column;  ^  —  unused  characters  in  buifer 
function  Position  return  Column;  —  used  characters  in  buffer 

—  this  procedure  creates  a  line  break  • 
procedure  NevLine; 

—  this  procedure  sets  the  indentation  increment 
procedure  Setlncrement( Depth i  In  POSITIVE); 

—  three  procedures  provide  indentation  operations 

procedure  indent;  —  increment  from  last  indentation 

procedure  Undent;  —  revert  to  previous  Indentation 

procedure  Setlndent( Pom r  In  Column); 

—  set  indentation  to  Poe 

end  FORMAT; 


Figure  9-1:  FORMAT  Package  Specification 
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pllcitly.  by  Invoking  the  function  NewUne.  or  ImjOllcttty  by  appending  text  beyond 
the  end  of  the  line.  At  each  line  break  a  new  line  is  started  by  moving  the 
position  to  the  current  Indentation  level  (whether  this  Is  done  by  actually  produc¬ 
ing  the  required  number  of  spaces  or  by  using  tabs  is  device  dependent  and  not 
considered) . 

The  Indentation  support  automatically  Indents  each  new  line  of  output.  The 
Interface  provided  by  FORMAT  allows  the  Indentation  to  be  incremented,  for 
typical  nesting  level  indentation,  or  to  be  set  to  a  specific  column.  The  model 
we  use  to  describe  the  operations  Is  a  LIFO  stack.  The  actual  Implementation  of 
the  operations  Is  hidden. 

3.3.1.  Output  Support  Operations 

The  Ada  program  source  program  has  four  classes  of  lexical  Items.  The  first 
class  consists  of  operators  and  delimiters.  Lexical  items  In  this  class,  such  as 
semicolons,  are  appended  to  the  buffer  using  the  procedure  Addtext. 

The  other  classes  are  Aoa  reserved  words.  Ada  identifiers,  and  comments. 
FORMAT  accounts  for  these  by  providing  three  additional  procedures  for  append¬ 
ing  text  to  the  output  stream.  These  procedures  receive  the  text  as  Input  and 
append  a  formatted  form  of  text  to  the  created  source  (the  Implementation  of 
how  the  text  is  formatted  Is  device  dependent  and  not  considered  here) .  The 
three  procedures  are  ResForm  (to  format  reserved  words).  ComForm  (to  format 
comments),  and  IdentForm  (to  format  Identifiers).  By  using  a  separate  proce¬ 
dure  for  each  class,  the  representation  of  the  class  In  the  output  text  can  be 
hidden  from  the  routines  recreating  the  source. 

Two  functions.  Remaining  and  Position,  are  provided  to  allow  Inquiry  Into  the 
status  of  the  current  output  line. 

3.3.  1.1.  Procedure  AddText 

The  simplest  formatting  operations  are  the  procedures  that  append  text  to  the 
output  stream.  The  most  straightforward  of  these  procedures  Is  AddText.  This 
procedure  appends  the  text  It  receives  to  the  output  stream  and  updates  the 
status  of  the  current  line. 


There  are  two  cases  to  consider  when  the  text  to  be  appended  Is  larger  than 
the  space  remaining  on  the  current  line.  If  this  Is  the  first  lexeme  after  the 
Indentation  then  the  Indentation  Is  reduced  to  accommodate  the  lexeme.  (The 
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lexeme  will  always  be  less  than  the  line  width  so  this  Is  possible  -  see  the 
assumptions  listed  In  Section  1.4.2  on  page  22).  Otherwise,  a  line  break  Is 
Inserted  Into  the  output  stream  and  a  new  line  Is  begun.  Inserting  the  line 
break  and  beginning  the  new  line  Is  achieved  by  calling  the  procedure  NewLlne. 
The  text  Is  then  appended  to  the  new  line.  t  NewLlne  causes  the  line  to  be 
Indented  properly) . 

After  the  text  has  been  appended  to  the  line  the  line  status  (current  position 
on  the  line  and  number  of  spaces  remaining)  will  be  updated. 

3.3.1. 2.  Procedure  ResForm 

Procedure  ResForm  appends  an  ADA  reserved  word  to  the  output  stream. 
Functionally  It  is  Identical  to  AddText.  It  calls  NewLlne  if  the  current  line  is 
exceeded  and  will  update  the  status  of  the  current  line  after  the  text  Is  ap¬ 
pended. 

The  representation  of  reserved  words  Is  not  specified.  The  way  in  which 
FORMAT  records  the  formatting  Is  also  not  specified.  If  the  output  Is  buffered. 
It  Is  possible  to  modify  the  buffer  so  that  each  character  can  be  given  an 
attribute  which  indicates  if  the  character  Is  to  be  printed  as  bold.  Italics,  or 
underlined. 

3.3.  1.3.  Procedure  IdentForm 

Procedure  IdentForm  appends  an  Ada  identifier  to  the  output  stream.  Func¬ 
tionally  It  Is  Identical  to  AddText  and  ResForm.  It  calls  NewLlne  If  the  current 
line  is  exceeded  and  will  update  the  status  of  the  current  line  after  the  text  Is 
appended. 

The  representation  of  Identifiers  is  not  specified.  The  way  In  which  FORMAT 
records  the  formatting  Is  also  not  specified.  If  the  output  Is  buffered.  It  is 
possible  to  modify  the  buffer  so  that  each  character  can  be  given  an  attribute 
that  indicates  If  the  character  Is  to  be  printed  as  bold.  Italics,  or  underlined. 

IdentForm  can  be  used  to  represent  identifiers  consistently.  For  example,  all 
Identifiers  can  be  normalized  such  that  the  first  letter  is  In  upper  case  and  the 
remaining  characters  are  In  lower  case.  The  representation  of  Identifiers  in 
Diana  is  not  specified.  The  Diana  producer2  that  creates  the  Diana  structure  is 
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not  required  to  preserve  the  case  of  identifiers. 

3.3.  1.4.  Procedure  ComForm 

Procedure  ComForm  appends  a  comment  to  the  output  stream.  Functionally  It 
Is  Identical  to  AddText  and  ResForm.  However,  since  a  comment  Is  terminated 
by  the  end  of  the  line.  ComForm  calls  NewLlne  to  insert  a  line  break  after  the 
comment  has  been  appended.  Of  course,  the  status  of  the  current  line  is 
updated  after  the  comment  is  appended. 

The  procedure  ComForm  receives  as  Input  an  Ada  comment.  The  comment 
Is  simply  an  Ada  text  string.  ComForm  appends  the  characters  * — *  to  the 
output  buffer  followed  by  the  comment.  Some  care  Is  needed  when  adding 
comments.  If  an  Insufficient  amount  of  space  remains  on  the  line  a  new  line 
must  be  started.  If  the  comment  extends  over  several  lines  the  comment  Is 

broken  at  the  space  nearest  the  end  of  the  line  and  Is  continued  on  the  next 
line,  again  beginning  the  line  with  the  comment  delimiter  * — *. 

3.3.1. 5.  Procedure  NewLlne 

The  procedure  NewLlne  inserts  a  line  break  into  the  output  stream  and 

creates  the  proper  Indentation  on  the  next  line.  The  indentation  Is  determined 

by  the  Indentation  operations  listed  below  In  Section  3.3.2.  Using  the  stack 

model,  each  time  a  new  line  Is  created  the  Indentation  at  the  top  of  the  stack  is 
read.  This  value  Is  the  number  of  blank  spaces  needed  at  the  beginning  of  the 
new  line.  The  way  NewLlne  creates  the  indentation  Is  possibly  device-dependent 
and  thus  not  specified  here  (e.g. ,  a  device  that  supports  tabs  may  use  tabs). 

3.3.  1.6.  Function  Remaining  and  Function  Position 

The  functions  Remaining  and  Position  provide  a  means  of  Inquiry  as  to  the 
status  of  the  current  line.  Remaining  returns  the  number  of  unused  characters 
at  the  end  of  the  current  line  and  Position  returns  the  current  position  on  the 
line.  The  sum  of  the  two  values  will  add  up  to  the  length  of  the  output  line. 
UneLength . 

3.  3.  2.  Indentation  Stack  Operations 

The  model  we  use  to  describe  the  operation  of  the  Indentation  support  is  a 
UFO  stack.  All  Indentation  of  the  source  program  is  properly  nested.  When 
there  Is  a  new  indentation,  the  new  value  replaces  the  old  value.  When  the 
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scope  of  the  indentation  Is  ended  the  text  Is  'undented'3,  that  Is  the  Indentation 
reverts  back  to  the  Indentation  In  effect  before  the  current  Indentation.  This 
proper  nesting  Is  well  modeled  by  a  stack.  Although  we  are  not  specifying  the 
Implementation  of  the  Indentation,  we  will  refer  to  the  operations  in  terms  of  a 
stack. 

The  FORMAT  entries  related  to  Indentation  are  Setlncrement.  Indent.  Undent. 
and  Setlndent. 

3.  3.  2.1.  Procedure  Setlncrement 

Setlncrement  receives  as  its  argument  the  maximum  nesting  depth  of  the 
program.  it  then  chooses  an  indentation  increment  based  on  this  number.  It 
tries  to  maximize  the  Increment,  to  make  each  Indentation  more  distinctive,  while 
keeping  the  maximum  excursion  small  (the  choice  of  how  far  across  the  line  the 
maximum  excursion  should  go  Is  not  specified) . 

3.  3.2.2.  Procedure  Indent 

Indent  increases  the  current  Indentation  level  by  a  computed  Increment  (up  to 
a  predefined  maximum  Indentation)  .  and  pushes  that  value  onto  the  stack.  For 
example,  if  the  current  line  Is  indented  ten  spaces  and  the  indentation  increment 
Is  five  spaces,  then  the  value  fifteen  would  be  saved  on  the  stack  as  the  value 
for  the  next  indentation. 

It  Is  possible  that  the  program  Is  so  deeply  nested  that  even  with  a  minimum 
Increment  the  Indentation  becoti.js  too  large.  A  maximum  indentation  Is  en¬ 
forced  to  ensure  that  there  is  reasonable  space  available  after  Indentation. 
When  the  maximum  is  reached,  an  additional  call  to  Indent  does  not  Increment 
the  Indentation:  It  pushes  another  copy  of  the  current  value  onto  the  stack. 

3.  3.  2.  3.  Procedure  Undent 

Undent  pops  the  last  indentation  value  off  of  the  stack.  This  operation 
reverts  the  Indentation  to  the  value  previously  in  effect. 

Note  that  setting  a  new  Indentation  level  (or  removing  It  through  Undent )  has 
no  Immediate  effect  on  the  output.  Indentation  occurs  at  the  next  line  break. 
When  the  line  break  occurs  the  value  at  the  top  of  the  stack  is  used  to 


3 


we  un  the  neologism  undent  for  convenience 


J 
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determine  the  indentation  for  the  next  line.  Line  breaks  are  Inserted  when 
appending  text  that  exceeds  the  remaining  space  on  a  line,  or  when  NewLlne  is 
called.  Thus  an  Indent  operation  followed  by  Undent  before  a  line  break  can  be 
inserted  has  no  effect  on  the  reconstructed  source. 

3.  3.  2.  4.  Procedure  Setlndent 

Setlndent  is  another  operation  on  the  Indentation  stack.  It  allows  the  inden¬ 
tation  to  be  set  to  a  specified  column.  Unlike  Indent  which  increments  the 
Indentation  by  a  fixed  Increment.  Setlndent  pushes  the  column  it  receives  as  its 
actual  parameter  onto  the  stack.  The  procedure  Undent  Is  used  to  remove  this 
Indentation  and  revert  to  the  previous  Indentation. 

Setlndent  is  useful  for  aligning  lexical  Items.  This  has  been  Illustrated  in 
Section  3.  2.  3  on  page  52 

3. 4.  Use  of  Format  Operations 

To  Illustrate  the  use  of  the  operations  of  the  package  FORMAT,  we  consider 
how  the  following  piece  of  Ada  source  could  be  formatted. 

procedure  £oobar(  paraxnl :  in  typel;  paxam2:  in 

type2 )  ia 

begin  statement 1;  —  comment l 

statement2 ;  end  £oobar; 

The  procedure  ResForm  appends  reserved  words  to  the  output  text.  In  this 
example  the  reserved  words  are  'procedure'.  "In'.  'Is',  'begin*,  and  'end'. 

The  Identifiers  Cfoobar'.  'paramV,  *param2*.  'type!*,  and  'type2')  are  ap¬ 
pended  using  the  procedure  IdentForm.  ComForm  is  used  for  adding  the 
comment.  We  assume  the  two  statements  are  short  enough  to  be  appended 
using  AddText.  The  following  lists  In  order  the  successive  calls  to  entries  in 
FORMAT  that  are  needed  to  format  the  source  code  in  the  example. 


: 


f 

'  s 


Formatting 
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(  ...) 

ReeFona( "procedure  ")> 
Identform( " foobar” ) ; 
JWMTert("("); 

Set Indent  ( Position ) ; 
IdentPorm(  "parami" ); 
(...) 

NewLine; 

IdentForm(  "param2" ); 
(...) 

Addtext( " )" )> 

Undent; 

ResForu( "is" ); 

NewLine; 

RssForm<  "begin" ) ; 

Indent ; 

NewLine; 

AddText( "  statement  1  > " ) ; 
ComForm<  "commentl" ) ; 
AddText ( "statement2 " ); 
Undent; 

NewLine  > 

ResForm(  "end  " ) ; 
IdentPorm( " foobar " ) ; 
AddText(  " ; " ) ; 

(  ...) 


—  includes  space  after  "procedure" 

—  set  indent  to  line  up  parameters 

—  here  "t  in  typel; "  is  output 

—  new  line  gets  indentation 

—  here  in  type 2"  is  outfit 

—  remove  indentation 

—  new  line  gets  no  indentation 

—  indent  by  increment  for  block 

—  new  line  gets  indentation 

—  » — «  ig  added  by  Conform 

—  undent  -  end  of  block 

—  new  line  gets  no  indentation 


The  resultant  formatted  program  Is  more  readable. 

procedure  foobar(  parami :  in  typel; 

param2i  in  type  2 )  jus 

begin 

statementl;  —  commentl 

statenant2; 


end  foobar; 
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CHAPTER  4 

RECREATING  FORMATTED  SOURCE 


This  chapter  presents  the  complete  design  of  the  Diana  to  Ada  pretty-printer. 
PrcttyPrint.  it  Is  a  blend  of  the  simple  source  reconstruction  described  In 
Chapter  2  with  the  formatting  operations  outlined  In  Chapter  3. 

The  formatted  source  Is  constructed  in  two  passes  over  the  DtANA-Ilke  struc¬ 
ture  (it  Is  In  fact  PP.Oiana.  a  refinement  of  Diana).  The  first  pass.  WALK*, 
computes  the  maximum  nesting  depth  of  the  program  and  the  number  of  charac¬ 
ters  In  the  recreated  source  disregarding  Indentation  a>'d  comments.  The 
second  pass.  WALK2.  reconstructs  the  source  using  the  formatting  operations  of 
package  FORMAT.  The  second  pass  uses  the  character  count  Information 
computed  In  the  first  pass  to  make  formatting  decisions  about  Indentation  and 
where  to  break  lines. 

This  chapter  begins  with  the  definition  of  the  refinement  of  Diana  that  defines 
PP_Olana.  a  structure  with  attributes  to  record  the  results  of  the  first  pass. 
Subsequent  sections  describe  the  two  passes  in  detail. 

4. 1 .  IDL  Refinement  ot  Diana 

The  IDL  design  provides  two  methods  for  defining  an  IDL  structure  in  terms  of 
a  previously  defined  IDL  structure.  Derivation  is  one  method:  Appendix  II  of  the 
ORM  describes  the  Ada  abstract  parse  tree  as  a  derivation  of  the  Diana  defini¬ 
tion.  Derivation  allows  the  deletion  and  addition  of  IDL  type.  node,  and  class 
definitions. 

Refinement  is  the  other  means  of  defining  a  new  IDL  structure  in  terms  of  an 
existing  structure.  In  refinement,  only  IDL  additions  are  permitted;  deletions  are 
not.  DtANA_Concrete.  defined  at  the  end  of  Chapter  2  ot  the  DRM.  Is  a 
refinement  of  Oiana.  For  a  complete  discussion  of  the  semantics  of  these 
features  of  IDL.  refer  to  the  *IDL  -  Interface  Description  Language  Formal 
Description*  [4], 

We  use  IDL  refinement  to  define  a  structure  that  Is  Diana  augmented  with 
attributes  for  pretty-printing.  We  add  three  attributes  to  the  structure. 

PP-jchara  All  nodes  have  this  attribute.  it  represents  the  number  of 
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characters  needed  to  print  the  text  for  the  node,  ignoring 
indentation  and  comments. 

pp_jnax_chara  This  Is  an  attribute  of  only  nodes  with  the  as_//sf  attribute. 

The  value  of  pp_rnax_chara  Is  the  maximum  of  pp_chara  for 
each  node  in  the  sequence  that  Is  the  aa_)lat  attribute. 

pp_Jndant  This  Is  an  attribute  of  the  root  node,  compilation.  The 

value  of  this  attribute  is  the  maximum  nesting  depth  below 
this  node.  It  measures  Indentation  only  for  block  and 
control  structure  nesting. 

The  refinement  of  a  structure  Is  specified  with  the  following  IOL  syntax. 

Structure  AnotherName  Refines  SomeName  is 

—  Additional  ZDL  statements  to  define  further  the 

—  structure  SomeName,  such  ae  a  specification  of  the 

—  internal  and  external  representations  for  private 

—  types  in  the  abstract  structure  Some name . 

—  New  nodes  may  be  defined. 

—  New  attributes  may  be  defined. 

End 

Consider  the  definition  of  the  IDL  structure  SomeName  described  in  Section 
Section  1.4  of  the  DRM  and  repeated  In  Figure  4-1  on  page  65.  Following  the 
definition  of  SomeName  In  the  same  figure  is  an  IDL  definition  of  the  IDL 
structure.  ReflnedName.  ReflnedName  is  a  refinement  of  the  IDL  structure 
SomeName  that  adds  the  attributes  pp_chara  to  the  nodes  tree  and  leaf. 

The  effect  of  the  refinement  Is  that  In  the  IDL  structure  ReflnedName.  the 
node  tree  now  has  the  attributes  op  and  arc  defined  in  the  IDL  specification  of 
SomeName.  and  the  attribute  pp_chara  as  defined  in  the  refinement.  The  effect 
is  as  if  the  node  had  been  defined  with  three  attributes  originally. 

We  define  a  refinement  of  Diana.  PP.Diana.  that  is  the  structure  necessary 
for  PrettyPrint.  The  entire  IOL  refinement  is  Included  as  Appendix  C. 

The  Input  to  PrettyPrint  is  Diana.  The  structure  that  WALK1  modifies  and 
WALK2  uses  is  PP_Oiana.  The  process  by  which  Diana  Is  modified  Into  PP_Diana 
is  not  specified  In  this  design.  It  Is  an  assumption  of  the  design  that  the 
operation  that  reads  the  Diana,  the  procedure  Gef_PP_7ree  of  package  MAIN. 
returns  to  MAIN  a  PP_Diana  tree. 

An  IDL  processor  can  be  used  to  create  the  Interface  programs  for  Pret¬ 
tyPrint.  An  IDL  processor  can  generate  both  a  reader,  to  read  an  ASCII 
representation  of  Diana  and  return  a  PP.Diana  tree,  and  an  interface  program 


—  First  we  define  a  private  type. 


Type  Source_Position; 


—  Next  v«  define  the  notion  of  an  expression,  EXP. 
EXP  : i-  leaf  I  tree  , 


—  Next  we  define  the  nodes  and  their  attributes. 

tree  ■>  opt  OPERATOR,  left i  EXP,  right »  EXP  ; 

tree  «■>  srct  Source  ..Position  ; 

leaf  ->  name  t  String  ; 

leaf  ->  arct  Source_Position  ; 


—  Finally  we  define  the  notion  of  an  OPERATOR  as  the 

—  union  of  a  collection  of  nodes ;  the  null  “>  productions 

—  are  needed  to  define  the  node  types  since 

—  node  type  names  are  never  implicitly  defined. 

OPERATOR  it-  plus  I  minus  I  times  I  divide  ; 
plus  ->  j  minus  ->  j  times  ->  »  divide  ->  » 

End 


—  Define  a  new  structure  by  refinement  of  the  old 
Structure  RefinedName  Refines  SomeNams  Is 

—  add  the  attribute  ppjchara  to 

—  leaf  and  tree 

tree  ->  pp_chara  i  Integer; 
leaf  ->  pp_charai  integer; 

End 


Figure  4-1:  Example  of  IDL  Refinement 
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that  receives  as  Input  the  Internal  form  of  Diana  and  returns  a  PP_Diana  tree. 
To  automatically  generate  the  interface,  the  IDL  processor  needs  a  specification 
of  the  process. 

An  IDL  process  specification  describes  the  structure  of  the  input  data,  output 
data,  and  the  Internally  used  data  structure.  Process  specifications  are 

described  In  the  IDL  manual.  A  simple  process  specification  Is  shown  below. 
In  the  example,  the  process  SomeProcess  Is  defined  as  a  process.  The  Input 
port  declaration  (begun  with  the  IDL  keyword  *Pre*)  names  the  Input  port. 
‘Inport*,  and  states  the  data  will  be  the  IDL  structure  ‘SomeName*.  Likewise  the 
output  declaration  names  the  port  ‘Outport*  and  defines  the  output  as  a 
‘ReflnodName*  structure. 

Process  SomeProcess  Is 

—  define  the  input  structure 
Pro  Inport  i  SomeName; 

—  define  the  output  structure 
Post  Outport  :  RsfinedNama; 

End 

Many  processes.  Including  PrettyPrint,  use  a  different  data  structure  inter¬ 
nally.  The  IDL  definition  of  the  process  PrettyPrint,  Figure  4-2,  has  an 
invariant  clause  ("inv  PP_Dlana‘>  to  show  that  PrettyPrint  uses  PP_Diana  inter¬ 
nally.  The  process  specification  for  PrettyPrint  does  not  specify  any  output. 
The  output  of  PrettyPrint  Is  a  text  file  which  Is  not  an  IDL  structure  and  Is  not 
considered  in  the  IOL  process  specification. 

The  process  specification  for  PrettyPrint.  shown  In  Figure  4-2.  defines  the 
necessary  Interface  for  PrettyPrint.  An  IDL  processor  can  take  this  specifica¬ 
tion.  along  with  the  definition  of  Diana  and  PP.Diana.  and  create  the  interface 
programs  for  PrettyPrint. 

4.1.1.  Operations  on  PP_Olana 

PP.Diana.  like  Diana.  Is  an  abstract  data  type.  In  Chapter  4  of  the  DRM  the 
Diana  operations  are  defined.  In  this  chapter  we  define  additional  operations  that 
access  the  attributes  defined  in  the  refinement. 


ii 


Chapter  4  of  the  DRM  provides  the  specification  of  the  Ada  package  Diana. 
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Process  PrettyPrint  Inv  PP_Diana  is 

—  PrettyPrint  uses  PP_Diana  internally 
—  the  only  input  is  Diana 
Pre  Inport i  Diana; 

End 


Figure  4-2:  IDL  Process  Specification  of  PrettyPrint 

The  package  is  also  discussed  In  Section  1.2.2. 1  on  page  9  of  this  document. 
The  package  Diana  provides  operations  on  the  Diana  data  type.  We  here  define 
the  package  PP^DIana  that  provides  the  operations  on  the  data  type  PP_Diana. 

Because  pp_Diana  Is  a  refinement  of  Diana,  the  package  must  contain  all  of 
the  operations  In  the  package  Diana.  In  addition,  the  package  must  contain 
operations  on  the  three  pp_  attributes  that  have  been  added.  Figure  4-3  shows 
the  package  that  defines  the  operations.  This  package  adds  six  new  operations. 
For  each  attribute  there  are  two  new  subprograms:  a  procedure  used  to  set  the 
value  of  the  attribute  and  a  function  used  to  read  the  value  of  the  attribute. 

With  USERPK;  UM  USERPK; 
package  PP_Diana  is 

(...) 

—  the  package  contains  every  operation  in  package  DIANA 

procedure  PP_CHARS( t i  in  out  TREE;  vt  in  INI’EUEK); 
function  PP_CHAR3( t t  in  TREE )  return  INTEGER; 

procedure  PP_MAXCHARS( t i  in  out  TREE ;  v;  in  INTEGER); 
function  PP _MAXCHARS( t :  in  TREE )  return  INTEGER; 

procedure  PP _NEST( 1 1  in  out  TREE;  v:  in  INTEGER); 
function  PP _NEST( t ;  in  TREE)  return  INTEGER; 

private 

(...)  —  not  considered  here 

end  PP.Diana; 


Figure  4-3:  PP.Diana  Operations 
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4. 2.  The  First  Tree  Walk  —  WALK! 

In  the  first  walk  over  the  PP.Diana  tree  the  values  of  the  pp_  attributes  are 
computed.  The  tree  walk  is  designed  to  use  the  general  tree  traversal  opera¬ 
tions  of  the  package  Diana  described  In  Chapter  4  of  the  DRM. 

In  essence,  during  the  first  pass  over  the  tree  the  number  of  characters 
required  to  print  each  node,  and  the  level  of  nesting  at  the  root  are  passed  up 
the  tree.  The  number  of  characters  needed  to  print  a  node  is  related  (through 
the  addition  of  a  constant)  to  the  number  of  characters  needed  to  print  the 

nodes  that  are  its  structural  descendants.  The  number  of  characters  needed  to 
print  a  leaf  of  the  tree  Is  related  to  the  length  of  its  lexical  Ux_symrep  or 

lx_numrap)  attribute. 

Similarly,  the  nesting  depth  below  a  node  Is  related  to  the  nesting  depth  of 
its  structural  offspring.  In  particular  each  offspring  is  indented  some  amount 

(possibly  zero)  from  the  parent  node.  This  amount  Is  added  to  the  nesting 
depth  of  the  child  and  compared  to  the  values  for  the  other  offspring.  The 
maximum  determines  the  nesting  depth  at  the  node.  The  nesting  depth  for  each 
leaf  is  zero. 

The  number  of  characters  required  to  print  a  node  is  needed  during  the 
second  walk  over  the  tree  and  is  recorded  at  each  node  as  the  pp_chara 

attribute.  The  nesting  depth  is  only  needed  at  the  root  so  compilation  is  the 
only  node  with  the  attribute  pp_peat.  (In  the  IOL  refinement  that  defines 
pP_Dlana.  in  Appendix  C.  pp_/»eaf  appears  in  only  one  place) . 

Nodes  with  asjlat  attributes  have  the  attribute  ppjmaxchara .  This  attribute 
stores  the  maximum  of  the  ppjshara  attributes  of  the  nodes  in  the  the  aajlat 
sequence.  This  value  is  recorded  for  use  In  the  second  pass  also. 

The  package  WALK1  specification  and  body  is  shown  in  Figure  4-4  on  page 
69.  The  package  specification  shows  that  one  procedure  is  exported,  also 
named  WALK1 .  and  this  procedure  operates  on  an  object  of  type 
PP_Dlana.TREE.  TREE  Is  a  type  defined  in  the  package  PPJDIana.  All  nodes 
in  PP__Dlana  are  of  type  TREE.  When  WALK1  Is  called  It  expects  to  be  passed 
the  root  node  of  a  PP_Diana  structure. 

The  package  body  shows  that,  'n  addition  to  WALK1 .  there  are  two  mutually 
recursive  subprograms.  Uatwalk  and  Nodawalk.  needed  to  traverse  the  tree.  In 
addition  there  are  two  constant  arrays  available:  Naat  and  Char.  The  following 
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—  Package  to  per Corn  the  first  walk  over  the  tree. 

with  PP_Diana;  use  PP_Diana;  —  DIANA  package,  for  pretty  printing 

pgflcags  waliu.  is 

procedure  WALKl(Tt  in  out  TREE); 
end  WAUC1; 


—  Package  to  perform  the  first  walk  over  the  tree, 
package  body  walki  is 

Son_Count  :  ARITIES  range  unary  . .  ternary; 

Nest;  constant  array  ( NODE JNAME , Son_Count )  of  NATURAL 
«“  (  •••  ); 

Char  t  constant  array  (NODE _NAME)  of  NATURAL 
«-  <  ..  )i 

function  Max(X;  in  NATURAL;  Y:  in  NATURAL) 
returns  NATURAL  is  separate; 

procedure  Listwalk(Node  >  in  out  TREE; 

Depth  j  out  NATURAL; 

Length  :  out  NATURAL; 

Maxbength  i  out  NATURAL); 

procedure  NodeWalk( Node  i  in  out  TREE; 

Depth  i  out  NATURAL; 

Length  i  out  NATURAL); 

procedure  Walkl(T:  in  out  TREE)  is  separata; 

procedure  Lis tWalk( Node  »  in  out  TREE; 

Depth  i  out  NATURAL; 

Length  i  out  NATURAL; 

MaxLength  i  out  NATURAL)  is  separate; 

procedure  NodeWalk( Node  i  in  out  TheEj 
Depth  i  out  NATURAL; 

Length  t  out  NATURAL)  is  separate; 


end  WALKI; 


Figure  4-4:  Package  Walki  Specification  And  Body 
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sections  define  Neat.  Char.  Llatwalk  and  Nodewalk  In  detail. 


4.2.1.  Subunit  Walkl 

The  subunit  that  defines  procedure  WALK1  Is  shown  In  Figure  4-5  on  page 
70. 


separate  (  walki) 

procedure  WalXl(T:  in  out  TREE)  is 

Depth!  NATURAL) 

Length!  NATURAL; 

Maxlength:  NATURAL; 

begin 

—  the  root  is  a  compilation  node,  to  be  treated  as  a  list 
—  List Walk  returns  the  nesting  depth  ->  Depth 

—  the  number  of  chars  ->  Length 

—  and  the  sire  of  largest  comp_unit  •>  MaxLsngth 

ListWalX  (T, Depth, Length, MaxLength); 

PP_CHARS(  T, Length ) ; 

PP _MAXCHARS(  T , MaxLength ) ; 

PP_INDENT( T, Depth ) ; 

end  WALlUj 


Figure  4-5:  Walkl  Subunit 

WALK1  receives  as  input  the  node  that  Is  the  root  of  the  source  program,  a 
compilation  node.  The  node  has  one  structural  attribute,  asjlat  that  Is  a 
sequence  of  comp_unlt  nodes.  The  function  LIST  returns  the  sequence.  WALK1 
calls  the  procedure  Listwalk  to  walk  down  the  sequence  computing  the  values  lor 
the  number  of  characters  (Length),  the  maximum  number  of  characters  In  any 
compilation  unit  (MaxLength).  and  the  maximum  nesting  depth  in  any  compilation 
unit  (Depth).  WALK f  then  uses  the  PP_Dlana  operations  to  set  the  value  of  the 
ppjshara.  pp_/naxchara  and  pp_peat.  Compilation  Is  the  only  node  with  all  three 
pp_  attributes. 
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4.  2.  2.  Nest:  Nesting  Constant  Array 

The  constant  array  Neat  Is  a  doubly-subscrlpted  array.  The  first  subscript  is 
for  indexing  by  node  type,  the  second  subscript  for  Indexing  by  the  structural 
offspring  of  a  node.  For  example,  the  entry  Neaf(dn_block.  2)  returns  the 
amount  the  second  child  of  the  block  node  Is  Indented.  Nodes  with  less  than 
three  offspring  have  the  value  zero  In  entries  for  non-existent  children.  Nodes 
with  no  offspring,  the  leafs,  have  the  value  zero  for  all  entries.  Nodes  with  the 
attribute  aa_llat  only  are  considered  to  have  one  child,  the  child  being  the 
sequence  of  nodes. 

As  an  example  we  consider  the  node  accept,  used  to  denote  an  accept 
statement.  The  Ada  syntax  for  the  accept  statement  's 

accepfc_Btatement  : i- 

acoept  entry_pame(  formal_part )  do 
eequence_o £_s t&fcemen be 
end  entzy_name; 


The  IDL  description  of  the  Diana  node  accept  is 

accept  ->  as_nama  s  NAME, 

as_param_assoc_s  •.  param_assoc_s, 

aa_atm_a  :  STH_S> 

The  first  and  second  children  of  the  node.  as_/»ame  and  aa_j>aram_aaaoc_ ja 
do  not  generate  text  that  Is  indented.  (The  attributes  represent  the  entry_name 
and  the  formal_part  respectively) .  The  third  child.  aa_atm_a  does  represent  text 
that  is  Indented,  the  sequence  of  statements.  The  value  of  Neat  for  this  node 
conveys  this  Information. 

Nest i  constant  array  (NODE_NAME,Son_Count)  of  NATURAL 

!•  (dn_accept  ->  (0,0,1),  —  only  Indent  the  third  son 

•  •  •  )  i 

Neat  Is  used  to  compute  the  nesting  depth.  For  each  node  loo.  the  nesting 
depth  for  the  /th  child  Is  the  nesting  depth  for  the  node  that  Is  the  child,  plus 
the  value  of  Nesf(dn_Foo. /) .  The  nesting  depth  for  the  node  Is  the  maximum  of 
the  nesting  depths  for  each  child. 

Note  that  the  nesting  depth  represented  In  Neat  Is  only  an  approximation  of 
the  indentation.  It  Is  possible  for  the  indentation  to  be  affected  by  other 
factors.  For  Instance,  a  statement  that  continues  beyond  the  end  of  a  line  may 
be  Indented  on  the  next  line. 
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4.2.2.  1.  Practical  Considerations  In  Nest 

The  value  of  Neat  for  the  node  record  accounts  for  the  nesting  of  Its  children 
and  the  fact  It  Is  nested  within  its  parent.  The  Ada  syntax  for  a  record  type 
specification  Is 

type_declaration  : 

type  Identifier  Is  type_deflnltloni 

record_type_definition  x x- 
record 

component_llat 
end  record 

In  general  the  type  definition  of  a  type  declaration  is  not  Indented.  However, 
when  the  type  definition  is  a  record  type  definition  the  keyword  'record*  should 
be  Indented.  This  Information  cannot  be  stored  with  the  node  type  so  It  is 
added  to  the  record.  The  value  of  Neat  for  record  would  ordinarily  represent 
the  fact  the  component  list  is  Indented  once  from  the  record  definition.  To 
compensate  this  value  Is  changed  to  two  to  account  for  the  indentation  of  the 
record  definition. 

Nest i  constant  array  ( NODE_NAME , Son_Count )  of  Integer 
i-  (drurecord  »>  (2,0,0),  ...  )> 

This  entry  Indicates  that  the  text  for  the  first  child,  the  component  list  of  the 
record  declaration,  should  be  indented  two  levels  from  the  rest  of  the  text  of  the 
node.  In  reality,  the  record  node  Is  Indented  once  and  the  component  list  Is 
Indented  once  again. 

4.2.3.  Char:  the  Character  Count  Constant  Array 

The  constant  array  Char  defines  the  number  of  characters  necessary.  In 
addition  to  the  structural  offspring,  the  print  the  node.  We  use  the  oxampfe  of 
a  record  type  specification. 

The  number  of  characters  to  print  the  record  definition  Is  the  number  of 
characters  for  the  component  list  plus  the  number  of  characters  needed  to  print 
'record  *.  and  'end  record*  (note  the  spaces  after  'record*  needed  to  separate 
the  text  from  the  component_llst) .  The  entry  In  Char  for  the  node  record 
reflects  this  knowledge. 

Char  i  constant  array  ( NODE_NAME )  of  Integer 
«-  (di\_record  ->  17,  ...)> 
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The  value  seventeen  indicates  that  printing  a  record  type  specification  requires 
seventeen  characters  In  addition  to  what  Is  required  to  print  the  componentjlst. 
Specifically.  the  seventeen  characters  are  'record  *  (seven  characters 
—  Including  the  space)  and  ‘end  record*  (ten  characters) . 

Note  that  Char  does  not  account  for  Indentation.  In  the  case  of  the  record 
definition  the  character  count  assumes  that  all  of  the  text  appears  on  the  same 
line. 

4.2.3.  1.  Practical  Considerations  in  Char 

There  are  some  character  counts  that  Char  cannot  represent.  The  most 

notable  Is  the  number  of  characters  for  variable  object  declarations  (and  constant 

t 

and  in  parameter  declarations) .  If  the  variable  object  declaration  has  a  defining 
expression  the  characters  ":=*  must  be  accounted  for.  If  the  expression  if 
absent  that  characters  will  not  appear.  The  value  In  Char  includes  the  count  for 
the  *:=*.  Although  this  affects  the  value  of  the  pp_chars  attribute  for  the  node, 
the  effect  can  be  accounted  for  In  WALK2.  When  processing  a  var  node  with  a 
void  as_joblect_de(.  WALK2  can  subtract  two  characters  from  the  total  represented 
In  pp_chara. 

There  are  other  Instances  of  small  Inaccuracies  In  the  generated  character 
count.  None  are  serious.  Although  the  global  total.  pp_chars  at  the 

compilation  node.  Is  only  approximate,  the  local  totals  needed  for  formatting 
decisions  are  accurate.  For  example  In  block  nodes  the  Ada  keyword  'declare* 
appears  only  when  the  node  represents  a  block  statement  with  a  non-empty  list 
of  declarations.  This  situation  is  not  serious  because  WA LK2  uses  the  character 
counts  to  determine  line  breaks.  In  a  block  statement  ‘declare*  Is  preceded  and 
followed  by  line  breaks  and  does  not  influence  the  line  break  decisions  for  the 
list  of  declarations. 

The  computation  of  the  length  of  lists  Is  tricky.  Consider  the  formal  part  of 
a  subprogram  declaration.  It  Is  a  list  of  parameter  specifications,  separated  by 
semicolons,  enclosed  by  parentheses.  The  number  of  semicolons  is  dependent 
on  the  size  of  the  list:  when  there  are  three  parameters  there  are  two  semi¬ 
colons.  WALK1  does  not  count  the  number  of  items  In  any  lists.  Char 
accounts  for  this  by  adding  one  to  the  character  counts  of  each  parameter 
specification  (they  only  occur  In  this  context)  .  and  accounts  for  the  extra 
semicolon  In  the  list  by  subtracting  one  from  the  character  count  for  the  formal 
part.  This  method  Is  also  used  for  Identifier  lists. 
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4.2.4.  Nodewalk 

The  subunit  for  the  procedure  Nodewalk  is  shown  In  Figure  4-6  on  page  75. 
The  procedure  NodeVYalk  Is  used  to  walk  down  the  structural  children  of  nodes. 
For  a  node  It  produces  two  out  parameters: 

Depth  the  nesting  depth  bel~w  this  node,  and 

Length  the  number  of  characters  needed  to  print  the  node. 

The  procedure  Nodewalk  traverses  the  tree  using  the  general  tree  traversal 
operations  supplied  by  the  package  Diana.  The  function  ARiTY  returns  a  value 
of  type  ARITIES  that  Indicates  the  structure  of  the  node,  i.e.,  the  number  of 
offspring  the  node  has: 

nullary  Indicates  no  offspring  (a  leaf). 

unary  indicates  one  offspring. 

binary  Indicates  two  offspring. 

ternary  Indicates  three,  and 

arbitrary  Indicates  the  node  has  as  its  descendant  a  sequence  of 

nodes  U.o.,  has  an  as J  1st  attribute). 

The  functions  SON1 .  SON2.  and  SONS  are  used  to  access  the  structural 
attributes.  The  functlor  SON1  returns  the  node  that  Is  the  first  child.  The 
subprograms  SON 2  and  SON3  similarly  return  the  second  an  third  offspring. 

The  function  KIND  returns  a  value  Indicating  the  type  of  node.  This  value 
can  be  used  to  Index  into  Char  and  Nest. 

Nodewalk  processes  the  node  based  on  its  structure,  using  the  value  returned 
by  ARITY  to  discriminate  between  nodes.  When  the  node  is  unary,  binary,  or 
ternary.  Nodewalk  Is  recursively  called  to  compute  the  values  of  nesting  depth 
and  character  count  for  the  descendants.  It  returns  the  nesting  depth  for  the 
node,  and  the  character  count  (the  sum  of  the  character  counts  of  the  children 
and  the  value  of  Char  for  the  node) . 

When  the  node  Is  nullary.  a  leaf,  a  further  discrimination  must  be  done. 
The  node  may  have  no  attributes  of  Interest  (such  as  null_statement) .  only  the 
Ixjsymrep  attribute,  or  only  the  lx__pumrep  attribute.  IDL  private  types  symbol_rep 
and  number_rep  are  implemented  so  the  function  Length  returns  the  number  of 
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separate  ( WALK1 ) 
procedure  NodewalX 

(Node  s  in  out  TREE; 

Depth  :  out  NATURAL; 

Length  i  out  NATURAL)  is 

LocalDepth,  RetumedDepth:  NATURAL  0; 

LocalLength, Returned Length :  NATURAL  0; 

LocalHaxlength  :  NATURAL  0; 

WhiChSon  :  TREE; 

begin 

case  ARITY(  rc.de )  is 
when  nullary  »> 

Depth  s-  0;  —  leaf  nodes  have  zero  nesting 

case  KIND( node )  is 

when  <in_and_then  |  (...)■> 

LocalLength  Char ( KIND( Node  )) ; 

When  dn_numeric_literal  -> 

LocalLength  :«  Length ( UC_NUMREP( node ) )  + 

Char(  KIND(  Node ) ) ; 

when  others  -> 

LocalLength  Length( LXLSYMREP( Node ) )  + 

Char( KtND(  Node ) ) ; 

end  case; 

when  unary  I  binary  I  ternary  *■> 

for  Son  in  unary  . .  ARITY( Node ) 
loop 

case  Son  is 

when  unary  -> 

WhiChSon  SONl(node); 

when  binary  «> 

WhiChSon  : -  SON2(node); 
when  ternary  -> 

WhiChSon  SON3(node); 

end  case; 

Nodewal£(  WhichSon,  RetumedDepth ,  Returned  length ) ; 

Depth  t-  Max(  LocalDepth,  RetumedDepth  +Nest(  KIND(  node ) , Son ) ) ; 
LocalLength  LocalLength  +  Re turned Length; 
end  loop; 
when  arbitrary  -» 

Listwalk(  Node ,  RetumedDepth ,  Returned  Length ,  Localmaxlength ) ; 

Depth  :«  RetumedDepth  +  Nest(KIND(Node),l\- 
Length  Returned Length  +  Char ( KIND( Node ) ) ; 

—  set  value  of  pp_maxchars 
PPJMAXCHARS( Node , LocalHaxlength ) ; 
end  case; 

PP_CHARS( Node, Length);  —  set  value  of  pp_chars  attribute 

Length  LocalLength; 

end  NodeWalk; 


Figure  4-6: 


Procedure  Nodewalk 
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characters  In  their  representation. 

When  the  node  Is  arbitrary  (Its  descendant  Is  a  sequence)  the  procedure 
Llstwalk  Is  called  to  process  the  node.  The  value  of  the  pp _maxchars  attribute 
Is  set  to  the  value  returned  by  MaxChar  of  Llstwalk. 

The  last  statement  of  the  procedure  sets  the  value  of  the  attribute  pp_chars. 
This  attribute  Is  recorded  with  all  nodes  In  the  tree. 

Note  that  when  Nodewalk  computes  the  number  of  characters  needed  to  print 
a  node  It  considers  neither  the  comment  for  the  node  nor  the  Indentation  of  the 
node.  The  value  of  pp_chars  represents  the  number  of  characters  needed  to 
print  the  source,  without  comments,  on  an  arbitrarily  long  line. 

4.2.5.  Listwalk 

The  subunit  for  the  procedure  Listwalk  is  shown  In  Figure  4-7  on  page  77. 
The  procedure  walks  down  a  sequence,  of  type  SEQ_TYPE.  and  produces  values 
for  three  out  parameters: 

Depth  the  maximum  nesting  depth  of  all  nodes  in  the  sequence: 

Length  the  number  of  characters  needed  to  print  the  sequence 

—  this  Is  the  sum  of  the  number  of  characters  needed  to 
print  each  node  in  the  sequence;  and 

Maxlength  the  maximum  number  of  characters  needed  to  print  any  one 

node  from  the  list. 

Llstwalk  receives  as  input  a  node  of  type  'arbitrary'.  I.e.  ,  a  node  with  an 
asjlst  attribute.  The  PPJDIana  function  LIST  returns  the  sequence  for  the  node. 
HEAD  returns  the  node  at  the  head  of  the  list:  TAIL  returns  the  sequence  that 
remains  after  removing  the  head.  The  function  IS_EMPTY  returns  true  if  the 
sequence  has  no  nodes.  Thus  the  inner  loop  is  executed  once  for  every  node 
in  the  sequence.  During  each  Iteration  the  depth  is  computed  to  be  the 
maximum  of  the  previously  computed  depth  and  the  nesting  depth  for  the  current 
node:  maxlength  Is  computed  analogously.  The  length  of  the  sequence  is 
computed  by  as  an  accumulated  sum. 

Llstwalk  does  not  set  the  value  of  any  attributes  directly  —  it  returns  values 
through  Its  out  parameters.  The  attributes  are  set  In  Nodewalk  or  WALK 1. 
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separate  ( WAUCl ) 

procedure  Lis tWalX( Node  i  in  out  TREE; 

Depth  t  out  NATURAL | 

Length  i  out  NATURAL; 

MaxLength  :  out  NATURAL)  is 
LocalLength , RetumedLength  :  NATURAL  :*■  0; 

LocalMaxlength  :  NATURAL  >■“  0; 

LocalDepth,  RetumedDepth  t  NATURAL  0; 

Seq;  SEC-TXPE; 

Hd i  TREE; 

begin 

Seqj-  LIST( Node ) ; 

LocalDepth  0;  LocalLength  i-  0;  LocalMaxLength  :=0; 

while  not  IS_EMPTY( Seq) 

loop 

Hd  HEAD (Seq)> 

NodeWalX(  Hd ,  RetumedDepth ,  RetumedLength ) ; 

LocalMaxlength  Maxintuni(  LocalMaxlength ,  RetumedLength ) ; 
LocalLength  s-  LocalLength  +  RetumedLength; 

LocalDepth  s-  Maximum( LocalDepth, RetumedDepth); 

Seq  i-  TAIL{ Seq); 
end  loop; 

Depth  LocalDepth) 

Length  ;*■  LocalLength; 

MaxLength  LocalMaxlength; 
end  ListWa  IX; 


Figure  4-7:  Procedure  Ustwalk 
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4.3.  Second  Tree  Walk  to  Generate  Formatted  Text 

WALK2  walks  over  the  PP_Oiana  structure  producing  formatted  source.  This 
pass  is  similar  In  structure  to  the  tree  walk  described  In  Chapter  2  In  that  It 
creates  the  source  as  it  walks  the  PP_Diana  structure.  It  is  different  in  that  It 
uses  the  operations  supplied  in  FORMAT  to  make  formating  decisions  as  it 
proceeds. 

The  package  specification  for  the  second  traversal  is  repeated  below. 


—  Package  to  perform  the  second  walk  over  the  tree. 

with  PP_Diana;  use  PP_Diana>  —  DIANA  package,  for  pretty  printing 

package  WAUC2  is 

procedure  WA1X2( T:  in  TREE); 
end  WALK2; 


The  package  body  for  this  package  is  very  large.  There  are  approximately 
160  mutually  recursive  procedures  used  to  traverse  the  tree.  The  package  body 
is  provided  In  Appendix  B. 

There  Is  a  procedure  for  nearly  every  Diana  node,  and  procedures  for  many 
of  the  Diana  classes.  In  particular,  not  every  Diana  class  Is  represented  by  a 
separate  procedure.  Classes  consisting  of  one  node  do  not  appear:  instead  the 
procedure  for  the  node  Is  used.  (These  cases  are  easily  recognized  in  Diana 
—  the  class  that  contains  only  the  node  *foo*  Is  named  'FOO') .  Further,  the 
nodes  in  the  classes  ID  and  OP  do  not  have  separate  procedures.  These  nodes 
can  be  processed  by  the  procedure  for  the  class  DESIGNATOR  since  all  nodes  In 
this  class  have  the  lx_symrep  attribute  and  the  only  text  associated  with  the  node 
Is  the  lexeme  contained  In  lx_symrep. 

Appendix  B  contains  the  package  body  for  WALK2.  Also,  a  few  of  the 
subunits  for  the  stubs  In  the  body  are  Included  in  this  appendix. 

The  naming  of  the  procedures  In  the  package  Is  straightforward.  The 
procedure  that  produces  formatted  source  for  the  node  too  Is  preceded  by  the 
prefix  "dp_*  to  produce  the  name  of  the  procedure:  *dp_foo\  Procedures  for 
IDL  classes  derive  their  name  similarly  from  the  class  name.  Class  FOO  Is 
processed  by  procedure  'dk_FOO‘. 
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4.3.1.  Use  of  Diana  Operators 

The  genial  node  operations  (SON),  SON2,  etc.)  are  used  for  the  first  pass 
over  \Pgrfree .  During  the  second  pass  the  tree  walking  procedures  are  more 
aprfc file  and  consequently  the  specific  Diana  node  operations,  operations  that 
address  attributes  by  name  (e.g..  AS_EXP) .  are  used.  (The  use  of  both 
traversal  methods  Is  driven  by  the  design  goal  of  stressing  the  package  Diana  as 
stated  in  Section  1.1  on  page  5. ) 

In  general,  there  are  two  operations  for  each  attribute,  that  Is  two  sub¬ 
programs  defined  In  the  package  PPJDIana.  The  operations  are  named  as  the 
attribute,  so  there  are  two  subprograms  associated  with  attribute  loo. 

procedure  POO  (ts  in  out  TREE;  vi  in  TREE)) 

—  This  procedure  sets  the  too  attribute  in  the  node  "t" 

—  with  the  value  "v" 

function  POO  (tt  in  TREE)  return  TREE) 

—  This  function  returns  the  value  of  the  loo  attribute  of 

—  node  "t" 

The  attribute  asjlst  Is  a  special  case.  The  function  LIST  returns  the  value, 
a  sequence,  of  type  (SEQ_TYPE.  Sequence  types  are  handled  using  the 
operations  HEAD.  TAIL,  and  IS^EMPTY  as  previously  described  In  Section  4.2. 

The  pp _  attributes  are  accessed  using  similar  operations,  described  in 

Section  4.  1. 

4.  3.  2.  Example  WALK2  Subunits 

In  this  section  we  present  two  sample  subunits  from  WALK2.  For  purposes  of 
comparison  we  reconsider  the  reconstruction  of  label  Identifiers  and  task  types 
that  were  first  Introduced  In  Chapter  2 

4.  3.  2.1.  Label  Identifiers 

All  Identifiers  are  processed  by  a  common  routine, 
procedure  dk_ID( Node i  in  TREE)  is 

—  dfc_ID  ia  used  for  all  identifier  nodes,  including  DEP_ID,  and  USED_ID 

—  since  all  elements  in  the  class  have  only  one  attribute  of  interest, 

—  they  are  all  processed  by  a  single  procedure 

begin 

IdentPorm(  UQ_SYMREP(  Node ) )  t 
end  dk_tD) 
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In  the  final  design,  the  treatment  of  the  labels  is  merged  into  the  procedure 
that  handles  sequences  of  Identifiers.  Here  a  check  for  the  type  of  the  node 
determines  If  the  identifier  is  to  be  bracketed.  In  addition,  some  formatting 
decisions  are  made.  The  length  of  the  sequence  Is  compared  with  the  remain¬ 
ing  space  on  the  line.  If  there  Isn't  enough  space  for  the  entire  sequence, 
then  each  Identifier  Is  placed  on  a  separate  line. 

procedure  dp_Id_s( Node t  in  TREE)  is 
Too long  t  Boolean; 

Seq  i  SEQ  TYPE) 

—  When  Too Long  is  true  put  each  identifier  on  a  separate  line. 

—  Checks  for  labels,  and  brackets  labels. 

begin 

Too  Long  Kax__Id_Width  <  P  P_  CHARS  ( Node  )  ; 

Seq  !•«  ZiIST(node); 

if  KIND( HEATH  Seq ) )  -  dn_label_id  then 
AddTextf -<<"); 
dk_ID( HEAD( Seq ) ) ; 

AddText( ">>"); 

else 

dk_ID(  KEADf  Seq  )  )  ; 
end  if; 

Seq  i-  TAIL(Seq); 
while  not  ISJSMPTY(Seq) 
loop 

if  KIND( HEAD( Seq ) )  -  dn_label_id  then 
if  Too Long  then  NewLine  end  if; 

AddTextf "<<"); 
dk_ID<  HEAD< Seq))> 

AddTextf ">»“); 
else 

AddTextf-,-); 

if  Too Long  then  NewLine  end  if; 
dk_ID(HEAD{Seq)); 
end  if; 
end  loop; 
end  dp_ID_S; 


4. 3.2.2.  Task  Types 

The  procedure  that  prints  all  type  declaration  must  determine  If  the  type 
specification  Is  a  task  declaration.  If  it  is.  then  the  keyword  ’task*  must  be 
printed.  The  procedure  below  Is  very  similar  to  the  procedure  In  Section 
2.2.2  on  page  35.  The  difference  Is  that  the  specialized  output  routines 
ResForm  and  AddText  are  used  to  create  the  output  line. 
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procedure  dp_Typs( Node i  in  TREK )  is 


if  KXND( AS _T*PE_SPEC( Node ) )  "  dn_task_epec  then 
ResPorm( "tasX  " ); 
end  ifi 

RsaPora<  “type  "); 
dkL.n>(  AS_rD(  Node  >  > ; 
dp_Var_a(  AS_VMt_S(  Node ) ) » 

Respond”  is  ~  )> 

<JK_TYPE_3PEC( AS_TYPE_SPEC( Node ) ) ) 

MdTe*t("j"); 
end  dpjrype; 
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APPENDIX  A 
FIRST  TRAVERSAL 


This  appendix  lists  the  Ada  package  WALK1  that  contains  the  procedures  to 
perform  the  first  tree-walk  of  the  Diana  tree.  The  discussion  of  this  package  is 
In  Section  4.2. 

A.  1.  Package  Specification 

—  Package  bo  perform  the  first  walk  over  the  tree. 

with  PP_Dlana>  uae  PP JDianaj  —  DIANA  package,  for  pretty  printing 

package  WAUC1  la 

procedure  WALK1(T:  in  out  TREE); 
end  WALK1; 
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A.  2.  Package  Body 


—  Package  to  perform  the  first  walk  over  the  tree, 
package  body  walki  is 

Son_Count  t  range  1 . . 3  > 

Nest:  constant  array  (NODE_NAME,Son_Count )  of  Natural 


i«  (  dn_record 

*> 

(1,0,0), 

dn_variant_part 

*> 

(0,1,0), 

dn_cond_c lause 

*> 

(0,1,0), 

di\_altemative_s 

»> 

(1,0,0), 

dn_altemat  ive 

*> 

(0,1,0), 

dn_loop 

•> 

(0,1,0), 

dnJslock 

*> 

(1,1.1), 

dn__package_spec 

*> 

(1,1,0), 

dn_task_spec 

*> 

(1,0,0), 

dn_accept 

*> 

(0,0,1), 

dn_ select 

(0,1,0), 

dn_«<elect_clause 

“> 

(0,1,0), 

dn_cond_entry 

*> 

(1,1,0), 

dix_timed_entry 

*■> 

(1,1,0), 

others 

-> 

(0,0,0)); 

Char  i  constant  array  ( NODE _NAME )  of  Natural 

i-  (  dn_pragma 

*> 

8, 

di\jparam_assoc_s 

*> 

1. 

dn_constant 

**> 

14, 

dr\_var 

-*> 

4, 

•  •  • 

drv_code 

•> 

o  ); 

procedure  Lis tWalk( Node  :  in  out  SEP  TYPE: 

Depth  >  out  Natural; 

Length  i  out  Natural; 

MaxLength  i  out  Natural); 

procedure  NodeWalk( Node  i  in  out  TREE; 

Depth  t  out  Natural; 

Length  t  out  Natural); 

procedure  walXl( T i  in  out  TREE)  is  separate; 

procedure  ListwaiX(Node  >  in  out  SE&_TYPE; 

Depth  t  out  Natural; 

Length  i  out  Natural; 

MaxLength  t  out  Natural)  is  separate; 

procedure  NodeWalX(  Node  i  in  out  TREE; 

Depth  i  out  Natural; 

Length  :  out  Natural)  is  separate; 


WALKI ; 
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A.  3.  Subunits 


separate  ( walki) 

procedure  WaUcl(T:  in  out  TR±— ;  is 

Depth:  NATURAL; 

Length:  NATURAL; 

Maxlength :  NATURAL; 

begin 

—  the  root  is  a  compilation  node,  to  be  treated  as  a  list 
—  ListwalX  returns  the  nesting  depth  ->  Depth 

—  the  number  of  chars  ->  Length 

—  and  the  size  of  largest  comp_unit  —>  MaxLength 

ListwalX  ( T, Depth, Length, MaxLength ) ; 

PP_CHARS( T, Length ) ; 

PP_MAXCHARS(  T, MaxLength ) ; 

PP_ INDENT( T, Depth ) ; 

end  WAUtl; 


separate  (WALKl) 

procedure  ListWalX( Node  i  in  out  TREE; 

Depth  :  out  NATURAL; 

Length  :  out  NATURAL; 

KaxLength  t  out  NATURAL)  is 
LocalLength.RetumedLengfh  :  NATURAL  :—  0; 

LocalKaxlength  :  NATURAL  0; 

LocalDepth ,  ReturnedDepth  i  NATURAL  i-  0; 

Seq:  SEQ_TYPE; 

Hd:  THKE; 

begin 

Seq:-  LIST(NOde); 

LocalDepth  :-  0;  LocalLength  :—  0;  LocalMaxLength  :-C; 
while  not  IS_EMPTY(  Seq) 

Xofy 

Hd  l-  HEAD(  Seq); 

Node«alX( Bd , ReturnedDepth ,  Returned Length )  > 

LocalKaxlength  Maximum(  LocalKaxlength, RetumedLength); 
LocalLength  t-  LocalLength  +  Returned Length ; 

LocalDepth  Maximum( LocalDepth, ReturnedDepth); 

Seq  TAXL( Seq ) ; 

end  loop; 

Depth  s-  LocalDepth; 

Length  :-  LocalLength; 

KaxLength  i-  LocalKaxlength; 
end  ListwalX; 
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•operate  (walki) 
procedure  NodeWalX 

(Node  t  in  out  TREE; 

Depth  >  out  NATURAL; 

Length  :  out  NATURAL)  ia 

LocalDepth,  ReL.  .rnedDepth i  NATURAL  t-  0; 

LocalLength ,  Re  tumedLength :  NATURAL  «*■  0; 

LocalMaxlength  :  NATURAL  0; 

WhichSon  i  TREE; 

begin 

case  ARXTY( node )  in 

when  nullary  ■> 

Depth  :«  0;  —  leaf  nodes  h^ve  zero  nesting 

case  KlND(node)  is 

when  dn_and_then  |  (...)  «> 

LocalLength  :»  Char( KIND( Node ) ) ; 
when  dn_numeric_literal  «> 

LocalLength  i»  Length( LXL.NUMR£P(  node ) )  + 

Char( KIND( Node ) ); 

when  others  ■> 

LocalLength  t*  Length(  U(_SYMREP(  Node ) )  + 

Char(  KIND(  Node ) ) ; 

end  case; 

when  unary  I  binary  1  ternary  -> 
for  Son  in  unary  . .  ARITY(  Node ) 

loop 

case  Son  is 

when  unary  -> 

WhichSon  !-  SONl(node); 
when  binary  «> 

WhichSon  SON2( node); 
when  ternary  »> 

WhichSon  SON3(node); 
end  case; 

NodeWalX(  WhichSon ,  RatumedDepth ,  Retumedlength ) ; 

Depth  Hax(  LocalDepth ,  RatumedDepth  +Neet( KIND( node ), Son )) ; 
LocalLength  «-  LocalLength  +  Returned Length; 
end  loop; 
when  arbitrary  -> 

ListwalX(  Node ,  RatumedDepth ,  Returned  Length ,  Localmaxlength ) ; 

Depth  i-  RatumedDepth  +  Nest(  KIND(  Node )  >  1 ) ; 

Length  ;«  Returned Length  +  Char(KIND(Node)); 

—  set  value  of  pp_tnaxchars 
PP_HAXCHARS(  Node ,  LocalMaxlength )  > 
end  case; 

PP_CHARS( Node, Length );  —  set  value  of  pp_chars  attribute 

Length  i-  LocalLength; 
end  NodeWalk; 
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APPENDIX  8 
SECOND  TRAVERSAL 


This  appendix  lists  the  Ada  package  WALK2  that  contains  the  procedures  to 
perform  the  second  tree-walk  of  the  Diana  tree.  The  discussion  of  this  package 
Is  in  Section  4.3. 

B.  1 .  Package  Specification 

—  Package  to  perform  the  second  walk  over  the  tree. 

with  pp_Diana;  use  PP_Diana;  —  Diana  package,  for  pretty  printing 

package  WALK2  is 

procedure  WAUC2(Tt  in  TREE); 
end  WAUC2; 

B.  2.  Package  Body 

—  Package  to  perform  the  second  walk  over  the  tree, 
package  body  WAUC2  is 

procedure  walk2(T:  in  TREE)  is  separate; 

—  procedure  stubs  for  the  second  traversal 

—  organized  by  Ada  LRM  chapter 

—  2.  Lexical  Elements 

— —  MaaaMBaaaamkHB 

procedure  dp_void  (Node:  in  TREE)  is  separate; 

—  2.3  Identifiers,  2.4  Numeric  Literals,  2.6  String  Literals 
procedure  dk_DES IGNATOR  (Node:  in  TREE); 

—  2.8  Pragmas 

procedure  dp_pragma  (Node:  in  TREE)  is  separate; 
procedure  dp _param_assoc_a  (Node:  in  TREE)  is  separate; 

—  3.  Declarations  and  Types 

—  3.1  Declarations 

procedure  dk_DECL  (Node:  in  TREE); 

—  3.2  Objects  and  Named  Numbers 
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procedure  dk_OBJECT_DEP  (Nodes  in  TREE)} 
procedure  d)^_EXP_VOID  (Nodes  in  TREE); 
procedure  dp_conatant  (Nodes  in  TREE)  is  separate; 
procedure  dp_var  (Nodes  in  TREE)  is  separate; 
procedure  dp_nuniber  (Node:  in  TREE)  is  separate; 
procedure  dp_id_s  (Nodes  in  TREE)  is  separate; 

—  3.3  Types  and  Subtypes 

—  3.3.1  Type  Declarations 

procedure  dp_type  (Node:  in  TREE)  is  separate; 
procedure  dXJTYT? E_SP EC  (Node:  in  TREE); 

—  3.3.2  Subtype  Declarations 

procedure  dpjsubtype  (Node:  in  TREE)  is  separate; 
procedure  dX_subtype_indication  (Node:  in  TREE); 
procedure  dp_constrained  (Node:  in  TREE)  is  separate; 
procedure  dX_constraint  (Nodes  in  TREE); 

—  3.4  Derived  Type  Definitions 

procedure  dp_derived  (Node:  in  TREE)  is  separate; 

—  3.5  Scalar  Types 

procedure  dK_RANGE  (Node:  in  TREE); 
procedure  dp_range  (Nodes  in  TREE)  is  separate; 

—  3.5.1  Enumeration  Types 

procedure  dp_enum_literal_s  (Node:  in  TREE)  is  separate; 
procedure  dX_ENUH_l.ITERAL  (Node:  in  TREE); 
procedure  dp_def_char  (Node:  in  TREE)  is  separate; 

—  3.5.4  Integer  Types 

procedure  dp_integer  (Node:  in  TREE)  is  separate; 

—  3.5.6  Real  Types 

—  3.5.7  Floating  Point  Types 
procedure  dX_RAKGE_VOID  (Nodes  in  TREE); 
procedure  dp_float  (Node:  in  TREE)  is  separate; 
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—  3.9.9  Mxsd  Point  Typaa 

pcooadura  dp.flaad  (Nodat  la  TREE)  la  aaparata) 

—  3  *■:  Array  Typaa 

pooaboa  dp.array  (Nodat  la  TREE)  la  aaparata; 
pcooaduza  dp_dscrt_ranga_s  (Nodat  la  TREE)  la  aaparata) 
pcooadura  dk_DSCRS_RANGE  (Nodat  la  TREE)} 
pcooadura  dp.lndax  (Nodat  la  TREE)  la  aaparata; 

—  3.7  Raooxd  Typaa 

pcooadura  dp.racord  (Nodat  la  TREE)  la  aapaxmta; 

pcooaduza  dk^CCKP  (Nodat  la  TREE)} 

pcooadura  dp_null_ooap  (Nodat  la  TREE)  la  aaparata; 

—  3.7.1  Diacriadnanta 
pcooadura  dk_VAR_3  (Nodat  la  TREE)} 
pcooadura  dp_var_s  (Nodat  la  TREE)  la  aaparata} 

—  3.7.2  Dlacrlainant  Constraints 

pcooadura  dp_daczat_aggcagata  (Nodat  la  TREE)  la  aaparata} 

—  3.7.3  variant  Parts 

pcooadura  dp_varlant_part  (Nodat  la  TREE)  la  aaparata} 
pcooadura  dp_variant_s  (Nodat  la  TREE)  la  aaparata} 

a 

pcooadura  dp_choica_s  (Nodat  la  tree)  la  aaparata} 
pcooadura  dp_varlant  (Nodat  in  TREE)  la  aaparata} 
pcooadura  dp_innar_racord  (Nodat  In  TREE)  la  aaparata} 
pcooadura  dk_CHOICE  (Nodat  la  TREE)} 
pcooadura  dp_othars  (Nodat  la  TREE)  la  aaparata; 

—  3.9  Aocas a  Typaa 

pcooadura  dp„accass  (Nodat  la  TREE)  la  aaparata; 

—  3.9.1  Xnceaplata  Typa  oaclaxmtlona 
pcooadura  dkjrrPE.SPBC  (Nodat  la  TREE); 

—  3.9  Daclaratlva  Parts 
pcooaduaa  dJt_mu  (Nodat  la  TREE); 


V 


i 
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gnoatat  dp_it **_a  (Nod*:  la  TREE)  1 a  aaparat*; 
v  '  —  4.  Ha—  and  Eiqpiz*saions 

pxooodur*  dkJNRME  (Nod*:  la  TREE); 

pcooaduz*  dp_u**d_char  (Nod*t  la  TREE)  la  aaparat*; 

—  4.1.1  Xndaaad  Components 
pcooaduz*  dOcJEXP_S  (Mod*:  la  TREE); 
pcooaduz*  dp_«qp_a  (Nod*:  la  TREE)  la  aapazat*; 
pcooaduz*  dp_ind*jc*d  (Mod*:  la  TREE)  la  aapazat*; 

—  4.1.2  Ellens 

pacooaduxn  dp_*lic*  (Nod*:  la  TREE)  la  aaparat*; 

—  4.1.3  S*l*ct*d  Components 

proondur*  dp_s*lected  (Mod*:  la  TREE)  la  aapazat*; 
pcooaduz*  dp_all  (Nod*:  la  tree)  la  aapazat*; 

—  4.1.4  Attributes 

pcooaduz*  dp.attribut*  (Nod*:  la  TREE)  la  aapazat*; 
pcooaduz*  dp_at tribut*_call  (Nod*:  la  TREE)  la  aapazat*; 

—  4.2  Iiitacals 

—  R*£*r  to  4.4.C  for  num»ric_ literal,  string_lit«ral, 

—  and  nuH_ace*ss. 

—  Raf*r  to  4.1  for  charact*r_lit*ral 

—  4.3  Jkqgrogatoa 

pcooaduz*  dKJDCP  (Nod*:  la  TREE); 
pcooaduz*  dp_aggz*gat*  (Nod*:  la  TREE)  la  aapazat*; 
pcooaduz*  4kJU*»J&aOC  (Nod*:  la  TREE); 
pcooaduz*  dp_nau*d  (Nod*:  la  TREE)  la  aapazat*; 

—  4.4  Expcvssiona 

pcooaduz*  dpjoinazy  (Nod*:  la  TREE)  la  aapazat*; 
pcooaduz*  dk_BXMMtr_OP  (Nod*:  la  TREE); 

(  pcooaduz*  dpL.and_th*n  (Mod*:  la  TREE)  la  aapazat *; 

pcooaduz*  dp_or_*la*  (Nod*:  la  TREE)  la  aapazat*; 
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I 


procedure  akjra* _ramqe  (Nodei  la  tree); 
procedure  dp_a— hsrshlp  (Nodes  la  tree)  la  separata; 
procedure  dkJMaeERSHZF.OP  (Mode;  la  TREE); 
procedure  dp_in_op  (Node;  la  TREE)  la  separata; 
procedure  dp_not_in  (Node;  la  TREE)  la  separate; 
procedure  dp_parentheslzsd  (Node;  la  TREE)  is  separate; 
procedure  dp_nun»ric_ li te ral  (Node;  la  TREE)  la  separate; 
procedure  dp_string_literal  (Node;  la  TREE)  la  asperate; 
procedure  dp_nulX_«ccese  (Node;  la  TREE)  la  separate; 

—  4.5  Operators  and  Expression  Evaluation 

—  4.6  Type  Conversions 

procedure  dp_oonvers ion  (Nodai  in  TREE)  is  separate; 

—  4.7  Qualified  Expressions 

procedure  dp.qualifled  (Node;  la  TREE)  la  separate; 

—  4.8  Allocators 

procedure  dp_al locator  (Node;  la  tree)  la  separate; 

—  5.  States ants 

—  5.1  Slaple  and  Coapound  statements  -  sequences  of  statements 
procedure  dp_sta_s  (Node;  la  TREE)  Is  separate; 

procedure  dkJRN  (Node;  la  TREE); 

procedure  dp.labeled  (Node;  la  TREE)  la  separate; 

procedure  dp_null_sta  (Node;  la  TREE)  la  separate; 

—  5.2  Assignment  Statement 

proaeduse  dp.essign  (Node;  in  TREE)  la  separate; 

—  S.l  If  Stat amenta 

procedure  dp_if  (Rode;  la  TREE)  la  separate; 
procedure  dp_ooad_elauee  (Node;  la  TREE)  la  separate; 

—  5.4  Csae  statementa 
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prooeaure  <5R_altemativa_e  (Modet  in  TREE)  la  separata; 
prooeaure  dp_altem*tive  (Modet  la  tree)  la  separate; 

—  S.S  Loop  Statesunta 

procedure  dp_naae4_»ta  (Modet  la  TREE)  la  separata; 
procedure  dfc_XTERftTIOM  (Modet  la  TREE); 
prooeaure  <3p_loop  (Modet  la  TREE)  la  aepexate; 
prooeaure  dp_for  (Modet  la  TREE)  la  aaparate; 
prooeaure  dp_reverse  (Modet  la  TREE)  la  separata; 
prooeaure  «Sp_ahile  (Modet  la  TREE)  la  asperate; 

—  5.6  Block  Stateawnte 

prooeaure  dp_>lodc  (Modet  la  TREE)  la  asperate; 

—  5.7  Brit  Stateaonts 

prooeaure  dfcJBMlJVOlD  (Modet  la  TREE); 

prooeaure  dp_exit  (Modet  la  TREE)  la  asperate;  —  is  no  nam  given 

—  5. S  Return  Stat; Quanta 

prooeaure  dp_retum  (Modet  la  TREE)  la  asperate; 

—  5.9  Goto  Statauents 

prooeaure  dp_goto  (Modet  la  TREE)  la  asperate; 

—  6.  fliftpingrsas 

—  6.1  Subprogram  Declarations 
prooeaure  dkJSOBPROCBtMtJDEP  (Modet  la  TREE); 


dpundspcogxaaudecl  (Modet  la  TREE)  la 
dkJBOEPJK»UXaC  (Model  la  TREE); 

and  ,argvuunt_id*  only  occur  in  the  predefined  envlronuent 
(Modet  la  TREE); 
dpjprooedure  (Modet  la  TREE)  la  asperate; 

4p_functlon  (Modet  la  TREE)  la  asperate; 

(Modet  la  TREE)  la  asperate; 

(MOdSt  la  TREE); 
dp_in  (Modet  la  TREE)  la  asperate; 
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procedure  dp_in_out  (Modat  in  TREE)  is  separata; 
procedure  dp.out  (Nodat  in  TREE)  is  separata; 

—  6.3  Subprogram  Bodies 

procedure  dEjBbOCXjnUB  (Modat  ia  TREE)} 

procedure  dp_subprograaj8ody  (Modat  in  TREE)  is  asperate; 

—  6.4  Subprogram  calls 

prooodura  dp_procedure_ca.il  (Nodst  ia  TREE)  is  separata; 
procedure  dp_ tunc t ion_cal 1  (Nodat  in  TREE)  is  separata; 
procedure  dk_PMMLA380C  (Modat  ia  TREE); 
procedure  dp.assoc  (Modat  ia  TREE)  is  separata; 
procedure  dk_jtCTOM.  (Nodat  ia  TREE); 

—  7.  Packages 

—  7.1  Package  structure 

procedure  dp_package_decl  (Modat  in  TREE)  is  separate; 
procedure  dk_PACXAGE_pEF  (Nodat  la  TREE); 
procedure  dp_package_apec  (Nodat  ia  TREE)  la  separata; 
procedure  dp_decl_s  (Nodat  ia  TREE)  is  separata; 
procedure  dp_package_body  (Modat  la  TREE)  is  separata; 

—  7.4  Private  Type  and  Deferred  constant  Declarations 
procedure  dp_private  (Nodat  ia  TREE)  is  separata; 
procedure  dp_l_private  (Modat  ia  TREE)  is  separate; 

—  «.  Visibility  Rules 

—  6.4  dee  Clauses 

procedure  dp_name_a  (Modat  la  TREE)  is  separata; 
procedure  dp.use  (Modat  ia  TREE)  is  separata; 

—  t. 8  Renaming  Declarations 

procedure  dpjrenmae  (Nodat  ia  TREE)  is  separata; 
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(Mod* i  la 


dp_ta*R_d*cl  (Mod* i  la 


4p_tasifc_MF*c  (Mod*t  in  TREE)  la 


diunoaunuBLVoxo  (Mod**  la  tree)) 


dp_ta*K_body  (Mod*!  la  TREE)  la 


—  9.5  Entries,  Entry  Calls  and  Accept  Statements 


dIUDSCRTJRMKMLVOZO  (Nod*!  la  TREE); 


dp_*ntry  (Mod*i  la  TREE)  la 


dp_*ntry_call  (Mod*t  la  TREE)  is 


dP_*co*pt  (Hod* i  la  TREE)  1s 


—  9.6  Daisy  Statements,  Duration  and  Tia* 


dp.dalay  (Nod*:  la  TREE)  la 


—  9.7  a*laot  statements 


9.7.1  Selective  waits 


dp_s*l*ct  (Nodei  la  TREE)  is  separate; 
dp_s*l*cty_claus*_s  (Modai  la  TREE)  la  i 


dp_jMl*ct_claus*  (Nod*i  la  TREE)  la 
dfcjnM  (Mod*!  la  TREE); 


dp_t*zainat*  (Modai  la  TREE)  la 


—  9.7.2  Conditional  Entry  Calls 


4P~condj*ntry  (Mod*i  in  TREE)  is 


—  9.7.3  Tlasd  Entry  calls 


dP_ti— dL*ntry  (Modai  la  TREE)  is 


—  9.10  abort  Sts  tenants 


dp_abort  (Mod*t  la  TREE)  la 


structure  and  Compilation  X; 
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—  10. 


—  10.1  Compilation  Units  -  Library  Units 


dp_ocmpi  1  at  ion  (Mod*!  la 


OUMmLEODT  (Mod* i  la 


(Mod* i  la 
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pcooadun  dp_ooep_unit  (Modes  la  TREE)  is  — parats; 

—  Context  clauses  -  With  Clauses 
procedure  (30c_00«TEXT_ELM  (Node I  la  TREE); 
procedure  dp.oonteat  (Modes  la  TREE)  la  separate; 
procedure  dp.with  (Nodes  in  TREE)  is  separate; 

—  10.2  Stibunits  of  Coapilatton  units 
procedure  dp_subunit  (Modes  ia  TREE)  is  separate; 
procedure  <Dc_3UBUMIT_BOOY  (Nodes  ia  TREE); 
procedure  dp.stub  (Modes  in  TREE)  is  separata; 

—  11.  Exceptions 

—  11.1  Exception  Declarations 
procedure  dkJEXCEPTZOMJJBP  (Nodes  la  TREE); 
procedure  dp.exception  (Nodes  ia  TREE)  is  separate; 

—  11.2  Exception  Handlers 

—  11.3  Raisa  Sta tenants 

procedure  dp_raise  (Nodes  la  TREE)  is  separate; 

—  12.  Generic  Proqree  Units 

—  12.1  Generic  Declarations 

procedure  dfc.GOIHRXCJBSIUDER  (Nodes  la  TREE); 
procedure  dp_generic  (Modes  ia  TREE)  is  separate; 
procedure  dp_generic_paree_s  (Modes  ia  TREE)  is  separate; 
procedure  dfcjNMERXCjPMWlt  (Nodes  la  TREE); 
procedure  aO^NNAZsjSUNPRDOJDEP  (Nodes  ia  TREE); 
procedure  dpjaor  (Nodes  ia  TREE)  is  separate; 
procedure  dp_no_de fault  (Nodes  ia  TREE)  is  separate; 
procedure  dfc_FORMftz*jr»Bjsrac  (Nodes  in  tree); 
pro  os  dure  dpjBorsal_dacrt  (Nodes  ia  TREE)  is  separate; 
procedure  dp_fomal_fiaed  (Nodes  la  TREE)  is  separata; 
procedure  dp_ fosneal, float  (Nodes  ia  TREE)  ia  separate; 
pcooedus*  dp_fCxeal_intagar  (Modes  ia  TREE)  is  separate; 
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—  12.3  Generic  Instantiation 

pcooaduxa  dp_gan*ric_assoc_s  (Nod*:  In  TREE)  is  separata; 
pcooaduxa  dp_lnstantiation  (Nodai  In  TREE)  la  ssparnts; 
pcooaduxa  dX_GENERIC_AS90C  (Modat  in  TREE); 

—  13.  Rspraaantation  Clausas  and 

—  ISplsnantation  oapandant  Features 

—  13.1  Raprasantation  clausas 
pcooaduxa  dk_REF  (Modat  in  TREE)) 

—  13.2  Length  Claus* 

—  13.3  Enusexation  Raprasantation  Clausas 
pcooaduxa  dp_sinpla_rap  (Modat  in  TREE)  la  aapaxata; 

—  13.4  Raoord  Raprasantation  Clausas 
procsdura  dp_alignaent  (Modat  in  TREE)  is  saparata; 
pcooaduxa  dp_caap_rap_a  (Modat  in  TREE)  is  aapaxata; 
pcooaduxa  dp_coap_rap  (Modat  in  TREE)  is  aapaxata; 

—  13.5  Address  Clausas 

pcooaduxa  dp_addxass  (Modat  in  TREE)  is  aapaxata; 

—  13.8  Machine  Coda  Insertions 
pcooaduxa  dp.codo  (Modat  la  TREE)  is  aapaxata; 

and  MUX2; 

B. 3.  8ubunHa 

aapaxata  (NALK2) 

pcooaduxa  M*Uc2(Nodet  in  out  TREE)  is 

—  Th*  root  nods  aust  to*  a  coapilation  nods 
Itagin 

dp_ooapilation(  Mod* ); 
and  8*1X2; 
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APPENDIX  C 

IDL  REFINEMENT  OF  DIANA  FOR  PRETTY  PRINTING 


This  appendix  lists  the  refinement  of  Diana  that  Is  used  for  the  pretty  printer. 
The  refinement  adds  three  attributes  to  Diana  that  are  useful  for  formatting  the 
recreated  Aoa  source.  The  attributes  are  discussed  in  Section  4. 1  on  page  63. 


Structure  FP_piana  Refines  Diana  la 

—  Pretty  Printer  Ba£inanent 

—  Version  of  1983  February  22 

—  2.  Lexical  Elements 


—  2.3  Identifiers,  2.4  Numeric  Literals,  2.6  string  Literals 

—  2.8  Pragmas 

pra^n  •>  pp_Charst  Integer; 

param_aseoc_s  «>  pp_Charsi  Integer, 

ppjnaxch&rs i  Integer; 

—  3.  Declarations  and  Types 

—  3.1  Declarations 


—  3.2  objects  and 
constant  •> 
ear  »> 
earjLd  ■> 
const_id  •> 
number  »> 
nusber.id  -» 
id_s  »» 


Numbers 

pp_charst  Integer; 

pp.charst  Integer; 

pp_chars i  integer; 

pp_chars ■  integer; 

pp_charst  Integer; 

pp_charst  Integer; 

pp.Charst  Integer, 
pp_puuocharst  Integer; 


—  3.3  Types  and  subtypes 

—  3.3.1  Type  Declarations 


type  -> 


pp.oharst  Integer; 


r 
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—  3.3.2  Subtype  Declarations 
subtype  «> 
subtype_id  «> 


pp.charsi  Integer; 


pp_charsi  Integer; 
pp.charst  Integer; 


constrained  -> 


pp_charsi  Integer; 


—  3.4  Derived  Type  Definitions 


derived  ■> 


—  3.5  scalar  Types 

range  -> 

—  3.5.1  EnuM ration  Types 

enun_literal_s  •> 


enun_id  **» 
def.ctiar  «> 

—  3.5.4  Integer  Types 

Integer  -> 

—  3.5.6  Real  Types 

—  3.5.7  Floating  Point  Types 


float  «> 


—  3.5.9  Fixed  Point  Types 
fixed  -> 


—  3.6  Array  Types 


array  •> 

dscrt_range_s  -> 


pp_charsi  integer; 


pp_dhars i  Integer; 


pp_Chars i  Integer, 
pp_eaaEChars  t  integer; 

pp.charst  Integer; 

pp_charsi  integer; 


pp_char»:  Integer; 


ppLChars i  Integer; 


pp_Chars i  Integer; 


pp_dharsi  Integer; 
pp_c!harsi  Integer, 

pp_*axchars t  integer; 


—  3.7  Record  Types 
record  •> 


pp.charst  Integer; 


pp.charst  integer, 
pp_naxchars i  integer; 


(-id  ■» 


pp.charst  Integer; 
pp.oharsi  Integer; 
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( 


—  3.7.1  Discriadnants 


ve*_e  -> 

pp_charsi  integer, 
ppjMngiharet  Integer) 

dscret _id  ■> 

pp.charst  integer) 

—  3.7.2  Diacriadnant  Constraints 

dacxat_aggzegate  -» 

pp.charst  integer, 
ppjnaxchars  t  Integer) 

—  3.7.3  variant  Parts 

variantupart  ■> 

pp.charst  integer) 

variant.*  •> 

pp.Charsi  integer, 
pp_aaxBhar*t  Integer) 

choice.*  ■> 

pp_charsi  integer, 
pp Lpaadhars «  Integer; 

variant  — » 

pp.charst  Integer; 

inner  ^record  ■» 

pp.charst  integer, 
ppjiaaCharat  Integer; 

others  *> 

jpp.chaxs !  integer; 

—  3.9  access  Types 

access  -> 

pp.Charst  integer; 

—  3.9.1  Incomplete  Type  Declarations 

—  3.9  Declarative  Parts 


itesu*  ■> 


—  4. 


end  Expressions 


used_obj#ct_id  -> 
ueed_naaw_ld  -> 
ueedJaltn-id  m* 


ueedJ»ltn_op  -» 


—  4.1.1  Indexed 


pp.charst  integer, 
pp_aaxcharst  Integer) 


pp_charsi  integer) 
pp.charst  integer) 
pp.charsi  integer) 
pp_charst  integer) 
pp_Charst  Integer) 
pp_dhaxst  integer) 
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exp_a  -> 

indexed  -> 

—  4.1.2  Slices 

■lice  *> 

—  4.1.3  Selected  Components 

selected  *> 
all  *•> 

—  4.1.4  Attributes 

attribute  »> 
attribute_call  -> 

—  4.2  Literals 

—  Rater  to  4.4.C  tor  numeric. 

—  and  null_acces*. 

—  Rater  to  4.1  for  character. 

■ —  4.3  Aggregates 
aggregate  ->> 

named  — > 

—  4.4  Expressions 

binary  -> 
and_then  *> 
membership  -> 
inuop  -> 

parenthesised  -> 
numeric. literal  -> 
string_literal  -> 
null_access  -> 

—  4.S  Operators  and  Expresi 

—  4.C  Type  Conversions 

conversion  »> 


pp.charst  integer, 
pp_maxchars>  Integer ; 

pp_chars«  Integer; 

pp_Chars i  Integer; 

pp.chars:  Integer; 
pp_chars i  integer; 

pp_chars<  Integer; 
pp_charst  integer; 

literal,  string_literal, 
literal 

pp_chars :  Integer , 
pgjmaxchars «  integer; 

pp.chare i  integer; 

pp.chars t  Integer ; 
pp.chars i  integer; 
pp_charsi  Integer; 
pp_chars i  Integer; 
pp_chars  t  integer; 
pp.charst  Integer; 
pp_chars i  Integer; 
pp.Charst  Integer; 
ilon  Evaluation 

pp.charst  Integer; 
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—  4.7  Qialified  Expressions 

pp_charsi  Integer) 

pp_chars i  Integer; 


—  5.1  Simple  and  Compound  Statements  -  Sequences  of  Statements 

ste_s  — >  pp_  chars :  Integer/ 

pp_naxchars:  Integer) 

labeled  *>  pp_chara»  Integer; 

label _id  «>  pp_chara»  Integer; 


qMalified  -> 

—  4.8  Allocators 

allocator  -> 

—  5 .  Statements 


5.2  Assignment  statement 
assign  -> 

5.3  If  Statements 
if  -> 

cond_clause  *> 

5 . 4  Case  statements 
case  -> 

altemative_s  -> 

alternative  «> 

5.5  Loop  Statements 
namsd_stm  -> 

loop  -> 
for  -> 
reverse  »> 
iteration_id  -> 
while  -> 

5.6  Block  Statements 


pp_charst  Integer; 

pp_chars  t  Integer , 
pp_maxchars :  Integer ; 

pp_charsi  Integer; 

pp_chars i  Integer; 

pp_char» i  Integer, 
pp_maxchars t  Integer; 

pp.charsi  Integer; 

pp_Charst  Integer; 
pp_Chars i  Integer ; 
pp_Chars  t  Integer; 
pp_Char» s  Integer; 
pp.dhazs i  Integer; 
pp_0hars i  Integer; 


blodk  -> 


pp.charst  Integer; 
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—  5.7  Exit  statements 

exit  •» 

pp.dharsi 

Integer; 

—  5.8  Return  Statements 

return  *> 

pp.Chars i 

Integer; 

—  5.9  Goto  Statements 

goto  »> 

pp_ chars ! 

Integer; 

—  6.  Subprograms 

—  6.1  Subprogram  Declarations 

sUbprograsutecl  m> 

pp_Chars i 

Integer; 

proc_id  -> 

pp_Charai 

Integer; 

functioo_id  — > 

pp_ charsi 

Integer; 

def_op  -» 

pp_Charai 

Integer; 

procedure  -> 

pp.chars t 

Integer; 

function  ”> 

pp_ Chars : 

Integer; 

pazaBL.s  •» 

pp.Chars: 

Integer, 

ppjsaxCharst  integer; 

in  -> 

pp_ chars « 

Integer; 

in_out  «> 

pp .chars i 

Integer; 

out  *> 

pp.chars i 

Integer; 

in_id  «> 

pp.chars i 

Integer; 

in.out.id  «» 

pp.chars i 

Integer; 

out_ld  ■> 

pp.chars i 

i 

c 

H 

—  6.3  Subprogram  Bodies 

subprograaijbody  •» 

pp .chars i 

Integer; 

—  6.4  Subprogram  calls 

procedure .call  -> 

pp.charsi 

Integer; 

fUnctlon_call  ■» 

pp.chars i 

Integer; 

assoc  »> 

pp.chars : 

Integer; 

—  7.1 


Structure 
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partcage_decl  -» 

pp_chars i  integer; 

package_id  -> 

pp.charst  integer; 

package_spec  «> 

pp_chaxei  Integer; 

decl_s  -> 

pp.charst  integer, 
pp_saachars  t  integer; 

packagojaody  -> 

pp.charst  integer; 

7.4  Private  Typo  and  Doforrod  Constant  Declarations 

private  »> 

1 _private  -> 

pp.charsi  Integer; 
pp_chars i  integer; 

private_type_id  «> 

pp_charst  Integer; 

l_private_typeJLd  -> 

pp_charst  Integer; 

8.  visibility  Pules 

8.4  Use  Clauses 

nan»_s  -> 

pp_charst  Integer, 
pp_maxchars i  Integer; 

use  «> 

pp_chars>  Integer, 
pp_jnaxchaxsi  Integer; 

8.5  Renaming  Declarations 

renas*  •> 

pp_chsrsi  Integer; 

9.  Tasks 

9.1  Task  Specifications  and 

TaSk  Bodies 

taSfcjdecl  -> 

pp_Chaxst  Integer; 

taSk^spec  -> 

pp_Charst  Integer; 

taskJsody  -> 

pp_Charst  integer; 

taskJaody_id  -> 

pp_Charst  Integer; 

9.5  Entries,  Entry  Calls  and  Accept  statements 

entry  «> 

pp_Charsi  integer; 

entry_ld  -> 

pp_0harsi  Integer; 

ontxy.call  -> 

pp_Charst  Integer; 

accept  -> 

pp.charei  integer; 

—  9.0  Do Lay  Statements,  Duration  and  Tlao 
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I 


delay  «» 

9.7  s*l*ct  Statements 
9.7.1  s*l*ctiv*  Malta 

a*l*ct  -> 

eelsct_clause_s  -» 

select_clause  -> 
terminate  -> 


pp.charsi  Znt*g*r; 


PP_Charat  Integer; 

pp_charai  integer. 
pp_jnaaccharst  integer) 

pp_chare :  integer; 

pp.charst  Integer; 


9.7.2  Conditional  Entry  Call* 

cond_ent*y  -»  pp.charsi  Integer; 

9.7.3  Tlaed  Entry  Calls 

tlaMd_entry  -»  pp_char*i  Integer; 

9.10  Abort  Statement a 

abort  «»  pp.charsi  Integer; 

10.  Program  structure  and  Coepilation  issues 
10.1  Compilation  Units  -  Library  Units 
compilation  ■>  ppjnestt  Integer;  — 


coepllation  «» 


pp.charsi  Integer, 
ppjnaxchars i  integer; 

pp.charsi  integer, 
ppjaascharsi  Integer; 


?_unit  «>  pp.charst  Integer; 

Context  Clauses  -  with  Clauses 


context  «> 


with  •> 


pp.charsi  Integer, 
ppjHuocharet  integer; 

pp_charsi  Integer, 
SP_jMaeharst  Integer; 


10.2  Subunits  or  Coepllation  Units 
stdBunlt  «>  pp.Oharst  Integer; 

stub  •>  pp.aharst  Integer; 

11. 


nesting 
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—  11.1  inception  Declarations 


exception  »>  pp_charsi  Intogori 

exoeption_id  «»  pp_charst  Integer; 

—  11.2  laoeption  Handlers 


—  11.3  Raisa  States ants 

raise  «>  pp.charst  integer; 

—  12.  Oeneric  Prograa  Units 

—  12.1  Generic  Declarations 


generic  -> 


pp_chars«  Integer; 


generlc_id  »> 


pp.charsi  Integer; 


generic_parax_s  m* 


box  »» 

£omal_dscrt  »> 
fonal.flxed  *> 
fomal.float  •> 
foraal_integer  •> 


pp.charst  Integer, 
pp_eaxcharst  Integer; 

pp.Charsi  Integer; 

pp.charst  Integer; 
pp.charst  integer; 
pp.charst  Integer; 
pp_chars*  Integer; 


—  12.3  Generic  Instantiation 


ganeric_assoc_s  ->  pp_charsi  Integer, 

ppjMJocharsi  integer; 

instantiation  *>  pp_charst  Integer; 

—  13.  Representation  clauses  and 

—  Isplexsntation  Dependent  Features 

—  13.1  Representation  Clauses 

—  13.2  length  Clause 

—  13.3  Xnumration  Representation  Clauses 


siapla_rap  -» 


pp.charsi  Integer; 


—  13.4  Record  Representation  clauses 


augment  •» 


ooeP-reP-A  -* 


pp.charst  Integer; 

pp.oharsi  Integer; 

pp.charsi  Integer, 
pp_xnsaharsi  integer; 


pp_ohars 


i  Integer; 
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—  13.9  address  clauses 

address  ->  pp_charst  integer) 

—  13. •  Machine  Code  Insertions 

oode  ->  pp.charst  integer; 

—  14.0  Input-Output 

—  I/O  procedure  calls  are  not  specially  handled.  They  are 

—  represented  by  procedure  or  function  calls  (see  6.4). 

—  Predefined  Diana  Environment 


attr_id  *»> 
pragss-ld  -> 


pp_Charet  Integer; 

pp_dharst  Integer, 
PP_MOBChare  i  Integer; 
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APPENDIX  D 
FORMAT  CONTROL 


In  this  appendix  we  present  the  ADA  pcckage  that  contains  the  subprograms  to 
do  the  formatting  of  the  reconstructed  source. 


D.  1.  Package  Specification 


—  Package  that;  provides  operations  to  format  reconstructed  Ada  source 


FORMAT  la 
Line Length; 

constant  POSITIVE  t»  120; 
type  Column  is 

O. .Line Length; 


AddText ( Text :  in  String); 
mdure 

ResForm( Text i  In  String); 
mdure 

ComPorm(Textt  in  String); 


IdentFonaf Text i  in  String); 
function  Remaining  return  Column;  — 

function  Position  return  Column;  — 

NewLine;  — 

Indent;  — 

Undent;  — 

procedure  SetIndent(Posi  in  Column); 


length  of  the  output  line 

position  on  the  line 

store  Text  into  the  output 

store  an  Ada  reserved  word 

store  a  coament 

store  a  program  idantifiar 

unused  characters  in  buffer 
used  characters  in  buffer 
output  new  line  with  indentation 
increment  from  last  indentation 
revert  to  previous  indentation 

set  indentation  to  Poe 


FORMAT; 
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